2 ms·
I work at a company who's entire business was written in stored procedures and it has been a massive source of complexity and pain for us. Here are my issues wi
by clutchski 15y ago
I work at a company who's entire business was written in stored procedures and it has been a massive source of complexity and pain for us. Here are my issues with it:
- Most web languages have a wealth of tools for testing, introspection and instrumentation that don't exist or are hacks in PL/SQL. Unit tests, basic logging, aspects that log function execution time, posting to error tracking & app metrics services, etc.
- PL/SQL is not expressive or concise. String processing, in particular, is a nightmare. This means more code, buggier code & thus reduced developer happiness.
- At scale, developers need to be parsimonious with joins in the data layer, otherwise partitioning is impossible. This is technically possible in PL/SQL, but runs completely against the grain of SQL, so I can't imagine this actually happening in the real world. This is probably my company's biggest source of technical debt.
- SQLPlus doesn't return a non-zero error code when certain errors happen when installing PL/SQL, so release scripts have to install then assert the user_errror table is empty. This is just ugly.
- Nerdfest 15y agoNumber 2 for me is the big one. PL/SQL (and any other SQL dialect I've worked with) is an exceptionally poor choice of languages for implementing business logic in.
- babebridou 15y agoNumber 3 is where the real money is. We had success with multiple schemas, using views and materialized views to partition everything we could, but both the good, the bad and the ugly in PLSQL come from the wonders of joining so it's always a very hard decision to make with high risk and high reward.