4 ms·
It's not that as simple as all that. Often the most expensive part of a database transaction is all the round trips back and forth while holding locks with an o
by eloff 7y ago
It's not that as simple as all that. Often the most expensive part of a database transaction is all the round trips back and forth while holding locks with an open transaction in the database. Move that logic into a stored procedure and suddenly your business logic can run in less than the time of a couple round trips to the database. Lock contention drops, number of concurrent transactions drops, and performance could actually increase. You scale the system vertically as long as you can, and then start partitioning and scaling it horizontally. You can go pretty far like that.
There are lots of other reasons this is a questionable idea at best, but performance is not necessarily one of them.
- JohnBooty 7y agoMove that logic into a stored procedure and suddenly your business logic can run in less than the time of a couple round trips to the database. Lock contention drops, number of concurrent transactions drops, and performance could actually increase Yes! A thousand times yes. This is especially important for write-heavy workloads. Releasing those locks and finishing those transactions ASAP is crucial. There are lots of other reasons this is a questionable idea at best, but performance is not necessarily one of them. When it comes to scalability.... yeah I think the 90/10 rule applies here. Probably the bulk of one's code can comfortably live up at the app layer. And the 10% of your code that's causing 90% of the bottlenecks is a candidate for solutions such as moving it down into the data layer, when feasible.