One of the most pernicious and pervasive myths in business-application development is that all business logic must be kept from the relational database and contained in a separate ‘business layer’. In the most fundamentalist forms of this idea, it’s just about OK to call a stored procedure to delete a customer, for example, but any logic, and other business processes associated with this operation, such as checking the customer’s outstanding balance is zero first, has no business being in the database. Since determining the valid range of values for a column is business logic too, that rules out use of database constraints, since that would simply be repetition of logic already in the business layer.

Where does one start? Firstly, it’s highly likely that all the actions that comprise a business function such as deleting a customer will need to be a transaction (otherwise, what if the balance is zero at the “check balance ” action, but non-zero by the time of the “delete customer” action?). In which case, the database is the eminently sensible place to host this logic. Secondly, if a database supports more than one business application, then the DRY principle makes the database the only sensible place to define common data-centric business logic. Thirdly, as Gail Shaw, or probably anyone else who spends much time fixing and tuning databases, will confirm, if we don’t create the necessary constraints in the database, then someone can and will find a way to bypass whatever checks exist in the application, and bad data will get in. As one commenter on Gail’s piece observes: “most developers…see their databases only as object persistence providers, not as data integrity guards. Old habits die hard”.

Businesses have always been faced with having to change their processes in the light of commercial, fiscal and regulatory changes. Applications must therefore be easy to maintain. This makes it important to avoid duplicating any business logic that is likely to change. The application architect, analyst and developer needs to determine the best place within the application for each business process. The transactional nature of the process is one of several factors to consider, but it is important.

The developer has a range of choices regarding the location of individual business processes, and it is easy to harm a project by getting it wrong. To restrict these choices arbitrarily seems an unlikely way of delivering better applications more quickly.