Object-Relational Mapping is the Vietnam of Computer Science(codinghorror.com) |
Object-Relational Mapping is the Vietnam of Computer Science(codinghorror.com) |
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".
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.
The basic argument seems to be that each ORM imposes limitations specific to that implementation which may result in the developer's choices being limited later on in the development process - just as early strategic decisions in a war can predetermine the outcome and potentially result in 'quagmire'.
It's an argument that seems to echo Joel's idea of "leaky abstractions", i.e. the ORM is just a big leaky abstraction and you have to deal with the leaks sooner or later.
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.
There are more problems with schema ownership, dual schemas, and refactoring.
Coding Horror lifts the summary and leaves behind all the argument
* 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
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.Did you consider using SQLObject or SQLAlchemy? If so, I'd be curious to know why you decided against using them?
Most client drivers/libs for RDBs have basic type conversions for each language. You don't always need an ORM for this. If you have a ruby or python Time object, the low level db lib generally will convert it to/from the RDB format.
I've used both simple and complex mapping methods. At the moment, I'm using mongodb with very simple first class object wrappers around the hash/dict. This is appropriate for this new app.
For an app I already have in production, I use postgresql and ruby's datamapper. This limits me to knowing that adding some features requires more work so those features keep getting pushed off the plate. The reason I use postgres for this app is because my users expect RDB ACID properties. For the new app I'm working on, not so much.
Didn't know that. If that's correct, then the low-level db lib is an ORM in Python. In which case SQLObject/SQLAlchemy probably just harnesses those features and adds some additional cream on top.
I had excellent engineering teachers. Never once did they compare the tough problems we were solving to Vietnam.
An ORM adds stuff on top of the driver. General these frameworks provide relationship management, connection pooling, caching, and config management.
Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages.
If you really want to know what's in various lower level drivers, as opposed to ORM frameworks (which vary quite a bit themselves), just go crack open some code and look at the APIs for yourself. You can go pretty far back to MS ODBC libs or even vendor dependent Oracle libs from mid to late 80s and see they were used quite effectively on their own for many years. JDBC was fairly straightforward derived from these predecessors.