Ad hoc queries vs stored procedures vs Dynamic SQL [closed]

Answer 1

IMHO stored procedures should be avoided like the plague. Here's ten good reasons off the top of my head for why you should never use them (applies to all databases):

1. The PL/SQL language is geared towards handling data in tables, rows and columns. It is a poor choice for expressing business logic. You can code anything in any language - that doesn't mean you should
2. Most databases lack a decent IDE to help with syntax and linking to other existing procedures (eg like Eclipse does for java)
3. Human resources are harder to find to write and maintain stored procedures - they are simply much rarer and therefore more expensive
4. Stored procedures are not portable between databases, because a) there is no industry standard for PL/SQL b) even if there was a standard, you usually end up using database-specific functionality/sql inside your stored procs. If you ever have to move dbs, you're looking at a full re-write of your business logic
5. Most databases don't offer any support for stored procedure debugging - you're left to insert rows into a log table or similar to achieve logging for debugging - very ugly
6. To test the stored procedure you need a real database instance. This makes unit testing stored procs difficult (you have to deploy them to a dev db to run them)
7. To deploy stored procs, you have to update the database (drop then create the stored procedure). If a bug is discovered, you can not simply roll back to a previous binary release like you can with app code. Instead, you must find the old code, drop the new stored proc and (re)create the old one. This is a change on top of a change, not a roll back
8. You are increasing the database server's processing demands, rather than distributing the business logic to other (app) servers. Since the database is usually a singleton, this is very bad, because the only way to increase capacity is to buy better hardware (not buy more hardware or use the cloud)
9. They are not that much faster than well written queries using prepared statements, because there's a trade off between increasing processing demand on the database server and the efficiencies of using them. Besides speed isn't everything (as long as it's acceptable): Maintainability, debuggability, suitability of PL/SQL, etc are just as important if not more so
10. Stored proc languages have limited (if any) libraries to draw upon, so you end up writing lots of low-value code. This is unlike app languages, which have loads of libraries you can use to all the things that business logic needs

There is only one place I would sanction their use: For very specific database functionality - perhaps a key check or a data type conversion or something similar, maybe within a trigger, that is so important it justifies its existence and that probably won't ever change once written.

In general, you should run screaming from stored procedures!