I agree 98% with this article, but as an architect we should never say never. There are circumstances when you would absolutely place business logic in a stored procedure.
You start with domain driven design, but there are many use cases that involve processing large amounts of data as quickly as possible. If you haven't read about "set theory", then you should. It boils down to math when you say you want to execute a function or set of functions on a large dataset as efficiently as possible.
I've seen very complicated stored procedures that modify large amounts of data where the performance would degrade significantly outside of the database.
But we should start with building a domain model and manage storage and performance as secondary interests. If, as we're designing our domain we see a lot of areas for high performance requirements, leveraging an engine (database or other) is a critical choice.
But in general, we should not be placing code in SQL. The domain of writing and reading business logic belongs in a standard programming language, not a data-oriented programming language.
Not a great example, and the Person table is not normalized. Building up a description to display is not even what I would call business logic. Some business logic naturally belongs in the database, some doesn't. Limiting the RDBMS (not SQL) to CRUD operations throws away too much. What the article describes is the opposite of 40 years of enterprise-scale experience with RDBMSs.
Think about a database that supports multiple applications written in different languages at different times by different teams. The problems with implementing business logic at the application level are more obvious then -- violation of the DRY principle, for one.
You start with domain driven design, but there are many use cases that involve processing large amounts of data as quickly as possible. If you haven't read about "set theory", then you should. It boils down to math when you say you want to execute a function or set of functions on a large dataset as efficiently as possible.
I've seen very complicated stored procedures that modify large amounts of data where the performance would degrade significantly outside of the database.
But we should start with building a domain model and manage storage and performance as secondary interests. If, as we're designing our domain we see a lot of areas for high performance requirements, leveraging an engine (database or other) is a critical choice.
But in general, we should not be placing code in SQL. The domain of writing and reading business logic belongs in a standard programming language, not a data-oriented programming language.