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 had to adapt their processes to shifting commercial, fiscal, and regulatory demands, which means applications must remain easy to maintain. For architects and developers, it’s much like managing compliance in industries that evolve quickly—Germany’s casino ohne oasis systems, for instance, are a recent case of regulation driving structural change. This reinforces why teams must avoid duplicating logic that’s likely to shift. The application architect, analyst, and developer need to decide where each business process belongs within the system. The transactional nature of the process is one of several factors to consider, but it’s a crucial one.

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.