I have a separate problem with stored procedures - it's pushing more and more work into the single hardest piece of software to scale - your database.
For the 99.999% of people who will never need to worry about Google or Facebook's "scale", stored procedures are absolutely the only sane way to build large systems.
I never understood this argument. Maybe you can elaborate a bit? Almost all our apps use sp for data lifting work (most of the so called "business logic"), and we never got scaling problems. Well, we don't have that much users or data either, but how many users/data do you have that your stored procs could not keep up with? What numbers are we talking about?
What makes the db slow is throwing bad sql at it, not Stored Procs.
> What makes the db slow is throwing bad sql at it, not Stored Procs
Absolute statements are absolutely wrong. :)
Particularly with DBs like PostgreSQL where you can (and people do) run Python scripts as stored procs. Great way to slow down your DB.
That is not much info :)
Just for reference: a simple query by pk index on my veryveryvery low end pc¹ on a table with 1mil rows takes about 0.04 ms (so says pgsql analyze). That is 25000 queries per second. What type of app are we talking here where the db needs to scale? Something like reddit? Stackoverflow? Just curious. Never saw such a beast where a DB server needs that much power. Where I work we have 200 apps on the same DB server, and it's idling most of the time.
¹i5 CPU 2.40GHz with 2GB of RAM
> run Python scripts as stored procs. Great way to slow down your DB.
There is more than one way to shoot yourself in the foot :)