3 ms·
Yep. Releasing, testing, debugging, etc are all more difficult in stored procs than in a “regular” language. Stored procs have other down sides: - often un
by Scubabear68 4y ago
Yep. Releasing, testing, debugging, etc are all more difficult in stored procs than in a “regular” language. Stored procs have other down sides:
- often unique to that DB, so locks you in
- Scaling that code is now tied to scaling your DB tier
- Tooling is often very inadequate
- Versioning and backwards compatibility of code can be a challenge
- rnk 4y agoSome of those concerns apply to any database. Your query could slowdown if the database picks a bad plan, so you could say you will never trust the db to scale. That's separate from scaling the stored proc - just using the db can run into a scaling issue.
- Scubabear68 4y agoNo, what I mean is your code scaling is now directly tied to how your DB scales. Your SP code can be impacting the rest of your DB, and vice-versa. I have seen large SP based systems to require Oracle boxes to be scaled up at enormous cost (hundreds of thousands or even millions of lines of SP). Not because of slow queries, but just the cost of executing the stored procs themselves.