

Object-Relational Mapping is the Vietnam of Computer Science - wyw
http://www.codinghorror.com/blog/archives/000621.html

======
jhancock
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.

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.

~~~
wyw
I think the comparison to Vietnam makes sense _as an analogy_.

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.

~~~
jhancock
The arguments in Atwood's and Neward's articles stand well on their own. The
war analogy is there as link bait.

~~~
wyw
If anyone could be accused of linkbaiting it would be Neward since he wrote
the original article titled "The Vietnam of Computer Science". But I think
it's less useful to think of the war analogy as linkbait than as a didactic
tool to bring attention to aspects of ORM use that Neward wished to highlight.
Creating effective analogies is the same strategy used by good teachers the
world over.

~~~
jhancock
The first thing wrong with this title is the article is about "software
engineering", not "computer science". The second thing wrong is engineering is
a discipline that teaches you about trade-offs, costs, and finding balance in
your solutions.

I had excellent engineering teachers. Never once did they compare the tough
problems we were solving to Vietnam.

~~~
wyw
Maybe they didn't compare tough problems to Vietnam but my point was that good
teachers often have a knack for translating difficult-to-grasp abstract
concepts into the familiar and the concrete. Some people look down on such
teachers and accuse them of dumbing things down. I would say on the contrary
that the job of a teacher is exactly to dumb things down.

------
russell
Neward's article is here:
[http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...](http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx)
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.

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

~~~
wyw
Yes, a mismatch exists and can lead to compromises as you try to use the
object paradigm to glue the two layers together. But the benefits are also
undeniable, primarily that of productivity gained during development by not
having to concern yourself with the job of mapping types between the two
layers.

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

------
Virax
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:

    
    
       * 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.

~~~
wyw
How do you map the types if the rows are returned as dicts? Doesn't that
become an application responsibility? By using an ORM you would not need to
build that functionality, i.e. reinvent the wheel.

Did you consider using SQLObject or SQLAlchemy? If so, I'd be curious to know
why you decided against using them?

~~~
jhancock
There are lots of ways to do this. A most common approach is to have each of
those dicts be a first class object in python/blub, and therefore you know the
class of the object. Customer.find() returns a customer which contains your
dict. No magic going on here. You are not reinventing too much by deciding to
use lightweight wrappers and eschew automated SQL generation or ORMS and
related DSLs.

~~~
wyw
You mentioned a "common approach". Is this the approach that you use or have
you found a better way? The reason I ask is I don't quite understand how your
description above correlates to an ORM type-mapping system. Customer.find()
returns a customer which contains your dict. I don't know python but I assume
a dict is a type-less hashmap. So if your customer has a field called
'updated_at', wouldn't you need to write a function to convert that type
appropriately for the application since the application doesn't know whether
it's a Date, Datetime or Timestamp?

~~~
jhancock
Yes, dict is a hash map. A python dict is not "typeless", it contains whatever
python objects you put in it.

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.

~~~
wyw
_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._

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.

~~~
jhancock
Most all low level rdb libs provide basic type conversion from allowed types
in the db to type fitting the language you are using. From these libs you send
SQL (any SQL you care to send) and you get returns of a "row" or a cursor
usually.

An ORM adds stuff on top of the driver. General these frameworks provide
relationship management, connection pooling, caching, and config management.

~~~
wyw
According to the Wikipedia definition of ORM, it's primarly about the mapping
of types:

 _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._

<http://en.wikipedia.org/wiki/Object-relational_mapping>

~~~
jhancock
Thats a pretty decent definition. I think their phrase "incompatible type
systems" is meant for you to stress the word systems. The word type is not
needed. Not to be confused with "type of an object, i.e. its class".

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.

------
keefe
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.

~~~
wyw
Usually the ORM has some notion of "associations" between models so that the
data relationships are easier to navigate from the application side.

------
joubert
I find that Core Data is pretty good.
<http://developer.apple.com/macosx/coredata.html>

------
erlanger
ORM is a tough problem. News at 11.

