Friday, November 28

orm lies

[Edit: when I originally wrote this, I was frustrated.  Looking back, I do not completely agree with how I expressed these ideas -- I think they have validity, still, but I doubt they convey that validity to the reader.   For the moment, though, I am going to limit myself to appending patches for what I think are the worst of the problems, in bracketed comments.]

ORM seems kind of neat, but it seems to be based on some lies [or, probably: mistaken understandings].

A fundamental lie [mistake] was espoused by C.J.Date (but I can't find his book where I read this): that you can not properly implement a relational database in an object oriented system.  

Here's an OO description of a relational database system:
  • A row encapsulates a table and an index into that table.
  • A table is a named collection of columns which all have the same length.
  • A column is an array of items which all have the same type.
How about the other direction?

Well, since a RDBMS has a specific object model, we probably should not expect that casting all objects into that model will be a good thing.  The whole point of an RDBMS is to organize data in a regular fashion, so efforts to use an RDBMS without organizing the data seem ... pointless.

That said, one of the objections raised about RDBMS has to do with the lack of support for encapsulation.  But in any decent RDBMS you have security which can disallow access to any part of the system.    Objecting that the administrator can have full access to the database is like objecting to the use of debuggers that can see private data in an OO system, or to the use of programming tools that can edit the private structure of a class.

Don't get me wrong -- SQL does not provide enough abstraction -- but given its relational roots I believe that that abstraction should have a certain character, and "object oriented encapsulation" doesn't really focus attention on the right areas.  But that's fuel for another rant.