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 collection. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com> On Sun, Sep 18, 2016 at 2:28 PM +1000, "Greg Keogh" <gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote: GL 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. GK
