I can't take seriously anyone who'd suggest putting everything into stored procedures.
Calling a stored proc for a simple select is often more expensive than executing it on its own, and procs should typically not be called from loop constructs or other stored procs due to the decision making the DBMS needs to perform on each procedure call.
Sure, your code may look a bit simpler, but your DB might not be so happy. | [reply] |
The idea is to abstract the business logic off to the stored procedures, so you'll be unlikely to be doing just a simple select.
Indeed, keeping everything the side of the database more often speeds things up in my experience. You're not moving data over the wire so all processing is happening locally. For example, doing anything involving iterating over a set of rows is likely to be a lot faster if you keep everything on the database side. It's also common to have more CPU cycles to play with on the database server too.
So I guess my experience is the opposite of yours :-)
This isn't to say I always think stored procedures are a good idea.
They are highly database dependant for example. If you're dealing with multiple databases, or if its possible you'll want to switch platforms, stored procedures are probably a bad idea.
Also, if you're only developing a single application then many of the safety advantages in isolating the business logic in the database disappear. An API in one language is just as good as an API in another. In this case it can make sense to keep everything in a single language so you don't have to find a PL/SQL (or whatever) coder for the team.
| [reply] |
