Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I've worked on a few systems that were stored procedure heavy with Microsoft SQL server, not so much because I am a .NET guy, some of these came when I was working on super-random projects for a consulting company.
My take is that it is a lot like building a system that has an API over the database except that instead of writing in API in, say, Java and exposing it through an http API with, say, JAX-RS, you are writing the API in stored procedures and accessing it through JDBC or ODBC or the native API of the database.
It seems very possible to build some thin layer that uses metadata to make an http API over stored procedures.
I'd say that systems like that can work very well.
The basic challenge is maintaining version control over your scripts, my coworkers were rubyists on my first such project and built a system inspired by migrations in Ruby on Rails where we wrote up and down migration scripts for every database change. I carried that approach to other projects where the people had less discipline to begin with. There is a little awkwardness there that the "down" script that reverts a procedure to a previous version has a cut-and-pasted copy of the old version of the stored procedure, if I had to do it over again I'd make something where each version of a stored proc is in a numbered file and the "migrations" just say "upgrade ABC proc to version 7" or maybe you could make something that looks into the VCS and finds the old version.
From what I've read, PL/SQL from Oracle looks a lot better than the Transact-SQL language in SQL server but I've never done a major project with Oracle. Most places I've worked at recently use PostgreSQL and I think this would be a viable architecture for that.
One area where it seems to be a hassle is with the "query builder" pattern, for instance where I work now we have a very complex search form with a huge number of options that builds a SQL query. I think you can do that kind of thing with what they call "Dynamic SQL", see
https://www.postgresql.org/docs/15/plpgsql-statements.html#P...
but it seems preferable to do that kind of thing with a real programming language, particularly if you have tools like
https://www.jooq.org/