Inhabitant of Carcosa :emacs: on Nostr: npub1fzx00…wt6h3 It's probably better now than it was 15 years ago, but back then, ...
npub1fzx00c36ny4whyuhg4ykx6987wxp885fmwmc784n27qcu6pavwzs3wt6h3 (npub1fzx…t6h3) It's probably better now than it was 15 years ago, but back then, the big problem with stored procedures was maintenance - related. The development environments for stored procedures were bad, the procedural languages were bad, the code lived entirely in the database, so you couldn't version control it directly; you could only version control a copy and hope nobody made the two diverge by working directly in the database. Also, until RDBMSs started building in JSON support, there wasn't really any generally useful output they could produce for web apps to use. I still have nightmares about mod_plsql.
There was also the idea, which is routinely violated today anyway, that you only want one (1) layer of your code to contain business logic, and since your application server has to have it regardless, that's the place to put it. Whether that was a good idea or not, the front-end demons drove a stake through that one years ago, so now it's axiomatic your business logic will be smeared across multiple code bases.
There was also the idea, which is routinely violated today anyway, that you only want one (1) layer of your code to contain business logic, and since your application server has to have it regardless, that's the place to put it. Whether that was a good idea or not, the front-end demons drove a stake through that one years ago, so now it's axiomatic your business logic will be smeared across multiple code bases.