OR mapping – opinion and issues.

September 21, 2006

Worm WheelOne of the biggest architecture decision which stares us on our face is whether to use OR mapping or not. The arguments in favour are very convincing, but does it apply in all scenario?

+ The most loved one (argument in favour) is that let the OO architects do a good job of Object design, let the DB architects do a good job of Entity-Relationship design and Map them using the OR mapping layer. You get the best of both worlds – a clean OO design and a good DB design.
+ The second one is that, since these layers can keep data in memory, so the performance improves.
+ Perhaps the most practical one I have seen is – in a software factory model – where developers generate database scripts from Java code, using OR mapping, hence your version control is in one place and there is no chance of forgetting to ship appropriate DB changes – which are not a natural part of your subversion ( or whatever source code repository you prefer)
+ The claims that programming is simpler as you only need to navigate objects and not entity-relationships which is not natural to OO programmers.
+ The claims that you need to write fewer lines of code.

The opposing camp is also very strong. It says
– You have to do the same design twice! Its better to design objects and optimize database. The relationships are at three places, Objects, OR configuration and in the database.
– Its slow, you dont get to tune the SQL Queries. You instead have to tune the database based on queries.
– Its slow, OR mappers get one row at a time
– Its a memory hog, objects un-necessarily reside in memory. If we want to cache, we will.
– It slows startup. Or if using lazy loading – its difficult to optimize. Also while using lazy loading It adds un-necessary code. You need to un-necessarily navigate thru objects to make sure that the child objects are loaded.
– The lines of code saved by not doing direct DB access are more than offset by the complexity of OR mapping.
– It becomes difficult to debug any data issues as it is difficult to understand the queries on the database and why they are what they are.
– In a clustered scenario, the OR mappers donot provide any great benefit of caching data as they always need to fire DB queries to ensure that the data is fresh.
The truth, as always, lies in between and is a bit grey.

In my experience, OR mapping works great in a situation – which are write heavy and where you work with one entity at a time. These include data entry intensive applications, some forms of customer service applications etc. And where the size of “actively used data” is small, – 1-2 GB max. Please note that I am talking about active data
and not the entire database.

OR mapping adds too much weight for read-mostly, report oriented applications, especially where you show grid of data on the UI, containing details from both parent and child objects. It can be used but the amount of tuning which is required either neutralizes or outweighs the benefits you get in the first place.

A hybrid model is also possible – and not exactly uncommon – but approach with caution as it has maintenance issues.
The bottom-line is that although OR mapping is a good thing in many scenario, but its heavy,complex,   doesnot solve all the problems and it takes a lot of time and effort to figure out how to use it effectively. You need to be very selective about where to apply it.


One Response to “OR mapping – opinion and issues.”

  1. OR Tools work well where the application does not too many Stored Proc’s. In case, the number of SP’s are more then, better stay away from OR mapping tools. Ideally, I have seen the 80/20 thumbh rule which works fine. If 80% of the database objects are tables, then use OR mapping tools, otherwise you are better off not using the same.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: