I’m known to hold Views (with an explicit capital) on the development of enterprise application software. Today’s post covers my View of the role and application or RDBMSes in enterprise applications and is summarised by the post title: I hold that the database is a bit bucket for the application and that it is mistaken to expand its responsibility beyond this.

By bit bucket I mean that the database is the container for the application’s data. It is responsible for the key concerns of storage, organisation and access of this data in a performant and transactional fashion. These are critical requirements of the application and today’s RDBMSes are sophisticated software systems that are extremely good at addressing them. Handing these responsibilities to such systems frees your application from the implementation of these concerns and in almost all scenarios (generally barring the very low and very high ends) is the rational and correct choice when implementing an enterprise application.

Where I believe some approaches are incorrect is when additional concerns are placed in the database, in particular when business logic is embedded in the database (via stored procedures and related mechanisms). It is my contention that putting such logic in the database has the following negative properties:

• The logic is obscured. Logic expressed in code will be more readily apparent in the development of the system as it will be a first class citizen within the system and not a constraint imposed by a dependency (the RDBMS)
• The logic will not be abstracted from the data representation. This will make it more complex and reduce its ability to be applied in different scenarios.
• Logic in code is more easily testable.
• Logic expressed in code may be varied at runtime much more easily.
• Performing complex logic in the RDBMS represents an additional burden on an element of the system that may not scale as easily or as far as a collection of application servers.

It could be argued that placing the business logic in a RDBMS allows it to be applied to multiple applications using a database in a consistent fashion. This argument is wrong and conflicts with another of my Views, that a database should be an implementation detail of a single system only. I may expand on this View in the future.

It is important to note that although it is appropriate to use an abstraction to the database and for that abstraction to consider the database to be a datastore only that we cannot ignore the characteristics of the database in using the abstraction. In particular if we ignore the performance characteristics of the database we are likely to end up with a system that cannot scale due to excessive interaction between the application and its database. This is generally a result of over-reliance on mechanisms such as lazy loading. We may consider the database to be a bit bucket but we must understand the costs of reaching into the bucket to retrieve our data and tailor our approach accordingly.

Reporting against the data in the database should also be considered. In general I consider reporting to be an alien creature performed by people who care deeply about graphing obscure metrics unrelated to things sane people consider. But that’s mostly so people don’t make me do it. Reporting is a critical concern of applications so that problems may be identified and informed business decisions made. Many RDBMSes contain inbuilt or coupled reporting capabilities, and a number of third party reporting solutions exist. These generally communicate directly with the database. I would not consider attempting to push reporting out of the database. This would be impractical and costly and to little benefit. Instead I would consider it to be a part of the database responsibility for storage, organisation and access to data.