Object-Relational Mapping is the Vietnam of Computer Science

I agree with Atwood's conclusion here. If you must use both an OO second tier and a RDB 3rd tier, concessions must be made. You can get around most concessions with more code at the hard parts, but sometimes its just not worth the effort. In addition to these concessions, there have been choices of OODBs for quite a while. We are now seeing some new DB choices come on the scene.<p>My perspective comes from having written what may have been the world's first ORM in Smalltalk in '88. I then spent the next 14 years building them over and over along with a full stack of other frameworks in Smalltalk and Java. Choices must be made. No framework is one size fits all. I generally sided with "make the easy things easy/automated and make the hard things possible/maintainable".<p>Is it Vietnam? No. You have far easier choices in how to develop your app than soldiers did in choosing wether or not to go to Vietnam. I wrote very hard ORM and other framework code; solved problems that enabled my customer's projects to be far more productive; was paid very well; enjoyed a good life; worked hard and was respected for my contributions. Hardly Vietnam.

Neward's article is here: <a href="http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx" rel="nofollow">http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...</a> There is a post elsewhere on HN that links to the wrong article. You have to skip forward a bit to get beyond the history of the Vietnam War to get to the meat.<p>The gist of the post is that there is a fundamental impedance mismatch between OO and Relational. If you try to apply inheritance to relational databases you get an unholy quagmire. My experience is that this is true. You get a rat's nest of tables and unwieldy joins.<p>There are more problems with schema ownership, dual schemas, and refactoring.<p>Coding Horror lifts the summary and leaves behind all the argument

I love the smell of sql in the morning ...

Talk about making a mountain out of a molehill. At my company, we don't try to turn database rows into objects. Here is how it works:<p><pre><code> * we use Python+MySQL * each table has an associated class, a CRUD-API if you will * a cursor object accesses a table like this: cursor.TableName.select_by_ids(low, high) * removing means set time_removed to the current timestamp * rows are returned as lists of dicts </code></pre> So the solution to the object-relational mapping problem is: for each table, there is a class that manages access to it, and a row is represented by a a dict.

What is an object, anyway? An object is a piece of data in memory, a set of fields and a set of pointers to other pieces of data. It's a live object in a small, closed world that is consuming a portion of a finite amount of resources. Consider the data in any kind of database - a traditional RDBMS or a triple store, data in such structures is much larger and cannot be loaded into RAM for querying, so indexes must be formed somewhere for querying. However you slice it, there will be a mismatch because of this scale difference. I recently wrote a utility class to automatically map objects to resources in an arbitrary RDF graph. The insight I gained from this was to consider that there exists a large, universal data model (defined in RDF in this case, could be defined in any way) that contains all the data, but is too large to load into ram. Querying this structure leads to a set of resources that represent the data that needs to be "alive" in objects in ram at the moment and then this data can be loaded into the objects, manipulated and serialized again. This is a bit of a rambling reply for something that is unlikely to be read but the point I am trying to make is that in data modeling we like to think of an open world of data but the reality of writing computer programs is working with a very small closed world of the data in RAM and object mapping highlights this issue, which is a difficult problem in general but which has numerous easy, ad hoc solutions.

I find that Core Data is pretty good. <a href="http://developer.apple.com/macosx/coredata.html" rel="nofollow">http://developer.apple.com/macosx/coredata.html</a>

ORM is a tough problem. News at 11.