3 ms·

I sincerely hope this will be downvoted out of sight so we won't be dealing with more dog slow sites. Moving business logic to essentially non-scaleable layer i

I sincerely hope this will be downvoted out of sight so we won't be dealing with more dog slow sites. Moving business logic to essentially non-scaleable layer is a terrible idea, benefits are so small compared to drawbacks

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 ago
  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 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.
weberc2 7y ago
It’s not a bad idea because it’s not well supported by current tooling and practices, not because of scalability. The scalability problem is tractable.
claytongulick 7y ago
Performance is the primary benefit for adopting the author's approach, actually. Normally the bottleneck of scaling an application is data access and storage, there aren't typically a lot of problems that are CPU bound. Adding additional layers doesn't increase performance, it increases latency and processing time. The closer you can keep your processing logic to the actual data, the better your performance is going to be. That being said, there are reasons why you may not want to follow that architecture, but generally performance isn't going to be one of them.

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 ago
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 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.

weberc2 7y ago

It’s not a bad idea because it’s not well supported by current tooling and practices, not because of scalability. The scalability problem is tractable.

claytongulick 7y ago

Performance is the primary benefit for adopting the author's approach, actually. Normally the bottleneck of scaling an application is data access and storage, there aren't typically a lot of problems that are CPU bound. Adding additional layers doesn't increase performance, it increases latency and processing time. The closer you can keep your processing logic to the actual data, the better your performance is going to be. That being said, there are reasons why you may not want to follow that architecture, but generally performance isn't going to be one of them.