I think there's a distinction to be drawn about logic being stored within the DBMS and logic being implemented and executed directly in the DB. Actually storin

I think there's a distinction to be drawn about logic being stored within the DBMS and logic being implemented and executed directly in the DB. Actually storing logic in the DBMS is often challenging unless you want to put a lot of effort in - source control tools and abilities to deal with multiple versions of logic are far less mature in the DBMS world, and while it's possible to make these work, you'll be doing a lot on your own to come up with something bespoke. But there's no reason you can't leverage the DB more directly from your backend code. Given the authors example of like code, that's already inefficient with a single row and would be a nightmare for multiple rows. It's perfectly reasonable to take code like that and have it directly execute SQL statements where a lot of logic is stored in the form of SQL, but still colocated with your application code rather than in stored procedures, triggers, etc. We do use an ORM for most of our DB interactions, but if something starts to stretch beyond the most basic of use cases, we're unafraid to drop to raw SQL and execute that instead. It's been a pretty happy medium for us.