3 ms·
The other side of the coin is that you probably won't need to scale. The performance differences can be staggering: I've replaced Java-based procedures which t
by radicalbyte 12y ago
The other side of the coin is that you probably won't need to scale.
The performance differences can be staggering: I've replaced Java-based procedures which took more than an hour to execute with Stored Procedures which completed within milliseconds. That's an extreme example - the original code was simply incompetent - but I regularly see significant (100x) performance increase in core functions through the switch.
Still, nowadays I prefer to have as much logic as possible in code because it's much easier to test and is more flexible than SPs; and it's always possible to move logic to SPs later..
- hobs 12y agoI see databases in general get a lot of flack from developers for this reason, when on the other side of the fence I see a lot of really smart people misunderstanding the tool (as your example alludes to.) I have often come to a stored procedure and not returned 100x, but more like 50,000x by simply changing a few lines of code. tl;dr anyone can write slow code in any language.
- radicalbyte 12y ago> I have often come to a stored procedure and not returned > 100x, but more like 50,000x by simply changing a few > lines of code. Oh, those beautiful nested cursors :)