Object relational mapping (ORM) is evil because it is the great big programmer hammer driving the square peg into the relational data round hole. ORM is a self-fulfilling prophecy; because it treats the RDBMS as a big dumb datasource then in fact it makes the database a big dumb datasource. Worse, it allows people to not think of database as being a collection of, y’know, relational data but instead as being a list of entities. That’s true if you are using an OODBMS but ORM doesn’t mean the same thing. ORM makes your RDBMS look a bit like an OODBMS by making the data model teh suck.

The biggest problem with programmers seeing the database through the ORM reality-distortion filter is that they start thinking that the entities they deal with are the data. In most cases that simply isn’t true, or if it is it is because the entities have started to become some kind of uber-object that contains everything about everything. The kind of object in fact that made people say EJB is slow.

If you take something like a sale in an online shop that sale means different things to different people. To the accountant it means margin, to the sales referrer it means commission and to the dispatcher it means a weight, volume and address, to the customer its just a credit card charge and a wheelbarrow (or whatever it is they’ve bought).

The amazing thing about about the RDBMS is that recognises this multi-faceted view of data and accurately decomposes it into the constituent elements. The dispatcher doesn’t have to see the sales commission, the accountant doesn’t have to see the item volume. You use queries to constitute a coherent and logical projection of the underlying data that can be defined by the purpose the data is going to be used for.

ORM fanatics rarely see things this way; instead they want to denormalise here and there, aggregate bits of data directly into the record, add a few nullable columns into the schema because, hey, the Java fields can be null. In short they want to make the schema reflect their view of the world. Because they don’t have to make sure that the various departments get their reports or that auditors have their clear and independent trail they tend to see themselves as the centre of the universe and whatever hellspawned application they are working on as the answer to all the “problems” in the big dumb datastores.

A lot of people complain if you propose splitting logic between layers. The trouble is that someone who bleats about splitting across layers will inevitably followup their complaint with the proposal that all the logic should, in fact, shock horror, be located in application X, their latest wonder-project.

This proposal never works and for one simple reason, if you don’t want to split logic between layers then you are committing yourself to adding every last feature of Oracle, MySql, DB2 or whatever into your application. Access control, query languages, caching, data intersections, transactions, you name it it is in the database for a reason. Unless you can reproduce these features in your application then forget about logic splitting because you should put function where it is best serviced.

ORM should see itself as just being one consumer of data and learn to play better with others. It should be about the convenience of presenting one valid method of data modelling in a form that is more familiar to programmers. It should take away any impedance due to having to comprehend the relational model (which I admit is hard) but it should leave it there and stop thinking that is the true answer to complex data issues.