| | 68 | |
| | 69 | ''A single table is how Ruby on Rails handles it. It does avoid the join problems, but your table could end up being pretty sparse... a lot of empty cells. (I know, but disk space is cheap... blah blah) The bigger reasons are that it makes it impossible to enforce NOT NULL constraints at the database level, and it may be easier to run into locking issues. There are generally 3 different ways to model inheritance for an ORM, this method offers the most "correctness" (if you put your dba glasses on) and the lowest performance for selects... That said, I don't think we're dead set on implementing things this way, but this *is* the way most people I've talked to are leaning.'' |
| | 70 | |
| | 71 | ''Here are a few references for those interested:'' |
| | 72 | * http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html |
| | 73 | * http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html |
| | 74 | * http://www.martinfowler.com/eaaCatalog/classTableInheritance.html |
| | 75 | * http://www.martinfowler.com/eaaCatalog/concreteTableInheritance.html |
| | 76 | |
| | 77 | ''-Joseph Kocherhans'' |
| | 78 | |
| | 79 | |