SQL is the clean interface. Databases are not designed to run your extra business computations, they are there to store and give you access to your data with efficiency and some guarantees. DBMS' are impossible to debug, cannot be shut down like you would with a faulty service node, and locking/crashing the production one can grind your entire company to a halt. The above pattern seems insane to me.
And is wildly misused. (edit: I meant "extra business logic" above, nothing to do with businesses). You commented above with the same thing I said - turns out multiuser DBs are not good for running expensive code beyond the data access stuff, because it interferes with their main job, in ways that are hard to diagnose or mitigate. Aggregation for business computations is fine, cleaning up text with regular expressions is borderline, and procedural code is a disaster waiting to happen. Putting a bunch of functions to hide the SQL in the DB itself to me seems to go against basic norms of how code is developed and deployed as application logic evolves, and not good architecture from risk standpoint either.
It was. But then it turns out databases were bad at handling or were expensive when there were multiple users connected. Setting up database connections didn't perform, so they had to be pooled. Row and field level security wasn't there, or with limitations. So we all migrated away to a different architecture. And perhaps we'll go back again, like we always do..
We try to put a clean API on everything, except the one place where it really matters...