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: www.sqldownunder.com<http://www.sqldownunder.com>
On Sun, Sep 18, 2016 at 2:28 PM +1000, "Greg Keogh"
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.