Which is better: Ad hoc queries or stored procedures? [closed]

Answer 1

someone said that recompile is a lazy excuse! yeah lets see how lazy you feel when you have to recompile and deploy your app to 1000's of desktops, all because the DBA has told you that your ad-hoc Query is eating up too much Server time!

is it good system architecture if you let connect 1000 desktops directly to database?

Answer 2

My answer from a different post: Stored Procedures are MORE maintainable because:

• You don't have to recompile your C# app whenever you want to change some SQL
• You end up reusing SQL code.

Code repetition is the worst thing you can do when you're trying to build a maintainable application!

What happens when you find a logic error that needs to be corrected in multiple places? You're more apt to forget to change that last spot where you copy & pasted your code.

In my opinion, the performance & security gains are an added plus. You can still write insecure/inefficient SQL stored procedures.

Easier to port to another DB - no procs to port

It's not very hard to script out all your stored procedures for creation in another DB. In fact - it's easier than exporting your tables because there are no primary/foreign keys to worry about.

Answer 3

Some things to think about here: Who Needs Stored Procedures, Anyways?

Clearly it's a matter of your own needs and preferences, but one very important thing to think about when using ad hoc queries in a public-facing environment is security. Always parameterize them and watch out for the typical vulnerabilities like SQL-injection attacks.

Answer 4

My experience is that 90% of queries and/or stored procedures should not be written at all (at least by hand).

Data access should be generated somehow automaticly. You can decide if you'd like to staticly generate procedures in compile time or dynamically at run time but when you want add column to the table (property to the object) you should modify only one file.

Answer 5

Stored procedures are definitely the way to go...they are compiled, have execution plan before hand and you could do rights management on them.

I do not understand this whole source control issue on stored procedure. You definitely can source control them, if only you are a little disciplined.

Always start with a .sql file that is the source of your stored procedure. Put it in version control once you have written your code. The next time you want to edit your stored procedure get it from your source control than your database. If you follow this, you will have as good source control as your code.

I would like to quote Tom Kyte from Oracle here...Here's his rule on where to write code...though a bit unrelated but good to know I guess.

1. Start with stored procedures in PL/SQL...
2. If you think something can't be done using stored procedure in PL/SQL, use Java stored procedure.
3. If you think something can't be done using Java Stored procedure, consider Pro*c.
4. If you think you can't achieve something using Pro*C, you might want to rethink what you need to get done.

Answer 6

There are persuasive arguments for both - stored procedures are all located in a central repository, but are (potentially) hard to migrate and ad hoc queries are easier to debug as they are with your code, but they can also be harder to find in the code.

The argument that stored procedures are more efficient doesn't hold water anymore. link text

Doing a google for Stored Procedure vs Dynamic Query will show decent arguments either way and probably best for you to make your own decision...