[dhd415]

Taking this approach to using a database is always a judgement call, but putting logic in the database is probably useful a lot more often than the "nine times out of ten" that the article claims. And the tradeoff in this approach contradicts the last line in the article: "Utilize the full extent of your database’s capabilities, but don’t put domain logic in it." Putting logic in your database is often necessary to make full use of its capabilities.

In applications with complex storage needs and/or performance-sensitive IO needs, I prefer to think about databases as an additional tier that provides complex storage services (as is precisely the case with most modern databases). As an example, I once worked on message routing and transformation server. From the perspective of the application logic, messages simply needed to be durably persisted and retrieved. At the level of the storage layer, I wanted message versioning, provenance, copy-on-write semantics to minimize on-disk size, and indexes to support at least two different retrieval patterns. All of the items at the storage layer were implemented in stored procedures. In other words, the database supplied a custom "storage API" to the business logic tier for persisting and retrieving messages that implemented those routines in a database-specific way that did not concern developers at the application layer.

The main arguments against this approach are:

* It will tie you to a specific database. This is true, but almost irrelevant since anything other than the most trivial usage of a database will inevitably make use of a feature or syntax specific to the database that would require modification were one to migrate to another database. Further, the mere idea of database independence is kinda' silly. No one talks about how writing your application layer in one particular programming language will limit the ability to migrate to another programming language. We should make technology choices around programming languages, databases, etc. with the intention of matching their strengths to the problem at hand fully understanding that tradeoffs are being made and that rework will be necessary if those choices are ever revisited.

* SQL used for writing stored procedures is not as good (for some definition of "good") as other programming languages used in the application layer. SQL is certainly different than most imperative or functional programming languages, but it's expressive and well-suited for its purpose. If you really need to make use of the capabilities of a database, it would behoove you to develop some proficiency in SQL.

* Putting logic in the database breaks modern CI/CD processes. IMO, this is the most compelling argument against it. That said, there is tooling that exists for putting stored procedure and other database logic in version control, automatically deploying it to a database, and running tests on it. These tools are not as commonly used, but they do exist. I've also used tooling that introspected the database objects such as stored procedures, etc., and automatically generated type-safe application code to interact with those database objects. That provided compile-time guarantees that application and database code were in sync at least with respect to number and types of arguments, etc. Whether it makes sense to go to the effort of integrating this tooling into your development process is a judgement call, but it can be done and I've seen it work well for application with demanding database needs.