Changes between Version 57 and Version 58 of ModelInheritance
- Timestamp:
- May 12, 2011, 3:31:11 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ModelInheritance
v57 v58 45 45 ==== 1. Modeling parent relations in SQL? ==== 46 46 47 The general conse sus seems to be this:47 The general consensus seems to be this: 48 48 49 49 {{{ … … 67 67 }}} 68 68 69 '' - Wonder what rationale was for choosing this approach? Collapsing into a single table (with discriminator) would alleviate the join problems. It would make for wide tables if the hierarchy was deep and each subtype added numerous attributes, but it would be hidden underneath the API anyway. Just wonderin... 70 71 - S 72 '' 69 '' - Wonder what rationale was for choosing this approach? Collapsing into a single table (with discriminator) would alleviate the join problems. It would make for wide tables if the hierarchy was deep and each subtype added numerous attributes, but it would be hidden underneath the API anyway. Just wonderin...'' 70 71 ''- S'' 72 73 73 74 74 ''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.'' … … 82 82 ''-Joseph Kocherhans'' 83 83 84 ''Thanks Joseph. Agree it's not an obvious choice. The Null thing is important, although wonder whether it's more important than performant queries... a bit philosophical that one: is it better to ensure cleaner data in the db or provide more performant code. It could be dealt with using triggers, but I know that then gets away from declarative constraints into procedural programming in the DBs. Aside from the different syntax, not all DBs even support triggers (sqlite?). 85 86 Stepping back, it's possible (likely) there will be situations where one or the other is preferred. It should be possible to allow for that by abstracting the approach into a Strategy (per Strategy pattern). Even though there's only one strategy provided initially, it would allow the (an-) other to be added later. Wonder if that's something you're considering? 87 88 - S 89 '' 84 ''Thanks Joseph. Agree it's not an obvious choice. The Null thing is important, although wonder whether it's more important than performant queries... a bit philosophical that one: is it better to ensure cleaner data in the db or provide more performant code. It could be dealt with using triggers, but I know that then gets away from declarative constraints into procedural programming in the DBs. Aside from the different syntax, not all DBs even support triggers (sqlite?).'' 85 86 ''Stepping back, it's possible (likely) there will be situations where one or the other is preferred. It should be possible to allow for that by abstracting the approach into a Strategy (per Strategy pattern). Even though there's only one strategy provided initially, it would allow the (an-) other to be added later. Wonder if that's something you're considering?'' 87 88 ''- S'' 90 89 91 90 ''Tangram, a Perl O/RM, allows both options. You can manually specify a table for a class, and if it's the table as the superclass, it does the right thing.''