 |
lua-l archive |
|
|
||
|
Petite Abeille wrote:
On Dec 20, 2009, at 1:56 PM, Richard Hundt wrote:Since this is OT, I'll just include a link to my response to the above here: http://bluehive.blogspot.com/2009/12/response-to-orms-being-veitnam-of.html"I'll start with the underlying assumption that an RDBMS must, by definition, have a "relational data model". This is not the case."Hmmm... right... in that case... if your database is simply a glorified key-value pair dump, then, yes, it doesn't really matter how you access your RDBMS as you are most likely not using any of its functionalities. But then again, why bother with a RDBMS to start with then?
No, you've missed the point.An object data model as a schema in a RDBMS is an approach to modeling domain objects, in the broadest sense -- so don't think objects as in Java, but objects as in "person" or "account" -- and as such has nothing whatsoever to do with stuffing [insert favourite OO language] objects into a database.
Not modifying a row's primary key isn't much of a restriction. Neither is ensuring that you describe your relations using foreign key to primary key. You can have all the cascading deletes, not null constraints, triggers and foreign keys you like. You can even think of your schema in terms of relational algebra or your data in terms of set theory for generating those reports for the marketing department, so long as you preserve "row" identity. Neither does it imply that you have anything remotely resembling an O/R layer over it.
It's just considered by many to be a "best practices" approach to modeling the problem domain, since the aim is to describe domain objects ("person", "user", "account"). It's natural, and happens to be what most of us do anyway. Formalised, you have a particular style of schema modeling which turns out to be more efficient.
What I was aiming at on my blog was that an ORM _can_ have all this as a natural consequence (for obvious reasons).