Code

Changes between Version 30 and Version 31 of ModelInheritance


Ignore:
Timestamp:
04/26/06 08:00:37 (8 years ago)
Author:
jkocherhans
Comment:

added more info on why we chose class table inheritance

Legend:

Unmodified
Added
Removed
Modified
  • ModelInheritance

    v30 v31  
    6666 - S 
    6767'' 
     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 
    6880=== 2. Modeling joins in SQL === 
    6981