Stored Proc biz-logic architecture was a big thing in the 2000s. MSSQL with its T-SQL were very common (and its polymorphic AND multi-table return types, could make for some very interesting control flows sometimes).
There was a lot of bitterness about it back in the late 00's and early 10's, and it drove a lot of ORM adoption.
I worked for a shop in the late 00's and early 10's that had Very Big Database Servers doing several hundred million transactions per second (100+ core, multiple RAMSan, etc. type bare metal servers), and stored procs were the way the go. They were basically the interface layer to the data, and it allowed us to keep the interface (or even version it) but change how access happened behind the scenes, like splitting a table into partitions, or replacing a bad performing query with a differently structured one that did better, which made it a non-concern for the frontend code that was responsible for getting data and formatting it, and didn't really care about _how_ that data was retrieved.
I worked for a shop in the late 00's and early 10's that had Very Big Database Servers doing several hundred million transactions per second (100+ core, multiple RAMSan, etc. type bare metal servers), and stored procs were the way the go. They were basically the interface layer to the data, and it allowed us to keep the interface (or even version it) but change how access happened behind the scenes, like splitting a table into partitions, or replacing a bad performing query with a differently structured one that did better, which made it a non-concern for the frontend code that was responsible for getting data and formatting it, and didn't really care about _how_ that data was retrieved.
reply