February 19, 2009 5 Comments
I’ve mentioned before that I’m lucky enough, given my own database-heavy focus, to be currently servicing a client whose applications tend to be database-heavy in terms of logic.
They are moving their applications gradually, yet wholesale and with no exceptions, towards an N-tier architecture throughout the company and their particular interpretation of N-tier means treating the database like a bit bucket (the only place I’ve been where they treat n-tier and database independent as synonymous although I know this is not an uncommon misunderstanding).
Today I had a conversation with one of the .Net developers along the lines of “you must be gutted given your database expertise.”
To which my response was that I was not particularly bothered which tier had the most lines of code – at the end of the day, it’s not a competition.
There are four things which primarily motivate me, or give me the most pleasure, in a professional capacity:
- Making slow, inefficient code fly.
- *Good design and good data modelling .
- Using databases efficiently.
*Incidentally, when designing and developing, I’m a great believer in the frequent need to not force it but wait for the right way to make itself known (at whatever time of day or night that might be).
So, moving a bunch of business logic (and in general very poorly written database logic) out of the database doesn’t bother me – the location of this logic doesn’t matter as long as it makes sense.
Remodelling and rearchitecting processes out of the database doesn’t bother me as long as it’s done accurately and properly wherever, and data is modelled appropriately.
In fact, the only thing which bothers me is that this rearchitecture is going to eventually involve Hibernate or similar, which will translate a single object save into a hundred individual insert or update statements, no bulk operations, nothing. I don’t like ORM (although I am very fond of OR views or an OR api in the database which can map one object save to as few operations in the database as is necessary).