Live data from Hacker News

Object-Relational Mapping is the Vietnam of Computer Science

codinghorror.com

11–20 of 29 posts

Re: Object-Relational Mapping is the Vietnam of Computer Science

#11
post #8

Earlier quoted context omitted.

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 "lea…

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

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.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#13
post #9
post #6

Earlier quoted context omitted.

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?

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.

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?

Re: Object-Relational Mapping is the Vietnam of Computer Science

#14
post #13
post #9

Earlier quoted context omitted.

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.

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…

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.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#15
Neward's article is here: http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute... 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

Re: Object-Relational Mapping is the Vietnam of Computer Science

#16
post #11

Earlier quoted context omitted.

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

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.

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.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#17
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.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#18
post #13

Earlier quoted context omitted.

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…

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 mo…

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.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#19
post #11

Earlier quoted context omitted.

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.

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.

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.

Re: Object-Relational Mapping is the Vietnam of Computer Science

#20
post #8

Earlier quoted context omitted.

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 "lea…

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

The Vietnam analogy is bad in many respects but I can see where they're coming from. ORM was a battlefield, many faught hard (including myself) and ended up walking way disgusted and defeated at the same time.
Post reply on HN