Wednesday, May 16, 2007

Of ORM

Really this is quite the rambling, I'm not exactly sure what it means, but it is a brain dump of some ORM related stuff that I've been thinking about for the past couple of days.

After having used Hibernate on a school project to help with object relational mapping (ORM) and now returning to an environment where I am writing all of my database code by hand, I understand why ORM is such an appealing solution. It isn't without its own headaches, but it does speed up development, because the developer isn't required to spend as much time on the data layer.

In the past month at work, I've spent most of my time writing service layers for a project that needs to support distributed API access by several applications across our line of business. To me it seems that when I am working on debugging code, more likely than not, the bugs appear in the data layer rather than in the business logic, or presentation layer. When I am debugging my data layer, or when I need to write yet another query to get at some aspect of the data, I am constantly faced with the question: why not use an ORM tool?

At my place of work the answer has been that ORM tools don't work well against legacy databases, and that they tend to add more overhead to processes that need to run really fast. Both arguments may have some validity. I have not yet tried to map objects against our legacy schema, and I do understand that if you one doesn't clearly understand the working of their ORM tool that some queries could end up being quite bloated. It is quite obvious that if all you need is a single field, and your ORM tool brings back 20, that's 19 fields that you didn't really need, but that argument sounds a lot like the argument that we should code every application in assembly because it would be very fast.

It was interesting to read a follow-up to this article in this month's Linux Journal. The Object Relational Mapping Quagmire, as the authors put it really needs some deep thought and attention. I think that they really hit the nail on the head. Yes ORM is nice because developers can deal with their happy objects, but relational databases and ORM don't have a perfect 1:1 correspondence because our objects hold information differently than our database tables do, and perfectly normalized data tables in BCNF will can cause a lot of pain for most ORM tools. It looks like there are some tools out there that aim to store data as objects rather than rows and columns, but that doesn't do much to solve the legacy database issue.

If a company currently does very well with the tools it has, and the legacy database it has supported for years, is it justifiable to start over? If it isn't broken, should it be fixed? I completely understand the decisions made by new companies to start out with the bleeding edge tools, but what about the legacy companies who have been making fine money with their tools for years? It's not an easy question, and I don't know that there are any exact answers. I don't believe that a company wants to be technologically stuck, but some upgrades seem almost prohibitive to the ever important bottom line. I'm a proponent for change, and it's always exciting to use the new tools, but re-structuring an entire database does seem counter-intuitive, even if I do have to write my DB code by hand.

No comments: