The Great DB Debate

I am currently working on an application that was very badly coded by another developer. Touching any part of the application is almost certain to embroil me in business rules, SQL statements, xhtml, Javascript, server side code or style sheets. Whatever I do, I almost always have to rely on my knowledge of the database to make a simple change to the application or fix a bug – there is no way around it. The database and the application are tightly coupled, and not even my client thinks of them as two separate entities.

I am inclined to make the decision that the business logic should live in the database, and that the database should be exposed to application developers by means of efficient and correct stored procedures. I am inclined to separate the responsibilities of team members:

• Web designers should build standards compliant web pages.
• Application developers should write server side code to fetch data from the database to be passed to templates that we built by web designers, or they should pass data to the database from the UI, responding to any errors that occur.
• A DBA should be responsible for building a database that performs well, is flexible and adheres to, expresses and applies business rules. And, the DBA should expose procedures that make the data available to developers

As far as I am concerned, the singers should sing and the dancers should dance. Even if I were the sole developer, I would be inclined to build things this way. I want it to be easy for my client to find someone to work on the application. If they want to change the look and feel, the should not have to hire someone who can write or read SQL statements.

I am attracted to ORM tools like Hibernate, or, in my word-a-day Microsoft centric world, NHibernate. I like SQLAlchemy, and SQLObject, and I agree with the goal they try to achieve. Application developers should be spared the pain and inconvenience of dealing directly with the database. Not all developers are able to build a good database, and not all applications should require them to mess with SQL. Fair enough. Ruby on Rails rocks for certain types of applications, and I can see why it is catching on.

However, I CAN build a good database, and I want to. I specialize in applications that contain many rules, and run against databases that may be required to grow and change over the years. Often, my databases have been used by multiple applications, not just one. I need to know that the rules will be applied well no matter what language is used to write the application. I also need to know that the database will perform well, and I do not want to rely on the poorly written queries the developers often write. (It is not their fault, DBAs do not always write good code.)

Since the dot com meltdown, many of my clients have started to look for the one-stop-shop. They would prefer to hire one developer to do all of the work in order to control the project budget. My experience, as a consultant who often gets asked to work on somebody else’s code, is that the one-stop-shop does not work. Often, the result is a bad database sitting under an inflexible web application that is not standards compliant.

Basically, I like stored procedures, and I am suspicious of frameworks and the magic they perform. In my own free time, I can see myself playing with Ruby on Rails, Turbogears, Hibernate, or some other framework. But, I would want the flexibility to use and take advantage of my database skills. Am I being a fuddy-duddy? I like MVC frameworks, but I still want to be use my database skills.

For a discussion of what some of us experience, see this complaint about Ruby on Rails in the enterprise.