Simple examples are anything many to many. If I have passengers on flights, I 
might have a Flights table, a Passengers table and perhaps some sort of 
FlightManifests table (who's on which flights).

But I sure wouldn't want those three as objects. I'd probably want a Passenger 
object with a Flights collection, and a Flight object with a Passengers 



Dr Greg Low
1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web:<>

On Sun, Sep 18, 2016 at 2:28 PM +1000, "Greg Keogh" 
<<>> wrote:


If your table design matches your object design, at least one of them is a poor 
design (again I'm talking about serious apps).

Then there's no hope. Game over man! It was easier for Jeff Goldblum to plug 
his laptop into an alien mothership that it is for coders and DBAs to exchange 
data effectively. Perhaps the relational database is a niche evolutionary 
branch that just gained too much popularity in the last 30 years and is now 
overused or incorrectly used and we all take if for granted. Robust RDBs come 
in all sizes and prices, many free, so they're just everywhere and you use them 
without thinking. Codd might regret his legacy!

You must have experienced many situations where some business data doesn't feel 
right in an RDB and you finish up with self-joins and tricks to mimic 
hierarchies, inheritance or represent temporal data. If other people have 
stumbled into this situation and have opted for an effective non-RDB solution 
then I'm keen to hear what happened.

In light of this whole discussion though, in future I'm going to be more 
careful about bridging the code-to-DB gap. Rather than just lazily spiting out 
wads of ORM generated code and throwing it at the DB, I'm going to consider how 
to use views and procs more effectively to do what they do best.


Reply via email to