Changes between Version 57 and Version 58 of ModelInheritance


Ignore:
Timestamp:
05/12/2011 03:31:11 AM (4 years ago)
Author:
jeroen.pulles@…
Comment:

Typo and markup fix

Legend:

Unmodified
Added
Removed
Modified
  • ModelInheritance

    v57 v58  
    4545==== 1. Modeling parent relations in SQL? ====
    4646
    47 The general consesus seems to be this:
     47The general consensus seems to be this:
    4848
    4949{{{
     
    6767}}}
    6868
    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
    7373
    7474''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.''
     
    8282''-Joseph Kocherhans''
    8383
    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''
    9089
    9190''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.''
Back to Top