When is it better to write “ad hoc sql” vs stored procedures [duplicate]

Answer 1

There's nothing about stored procedures that makes them magically speedier or more secure. There are cases where a well-designed stored proc can be faster for certain types of tasks, but the reverse is also true for ad hoc SQL.

Code the way you find most productive.

"Make it right before you make it faster." -- Brian Kernighan

Answer 2

If you are not writing stored procedures, investigate parameterized queries. If you build the SQL yourself including parameter concatenation, you're inviting a SQL injection attack.

Answer 3

A lot of thins have been said about performance, caching, and security in this thread already, and I won't repeat those points. There are a few things that I haven't read yet in this thread, which is portability issues and rountrips.

• If you are interested in maximum portability of your application across programming languages, then stored procedures is a good idea: the more program logic you store in the database outside the app, the less you have to recode if you're moving to another framework or language. In addition, the code to call a stored procedure is much smaller than the actual raw SQL itself, so the database interface in your application code will have a smaller footprint.
• If you need the same logic in multiple applications, then stored procedures are a convenient to have a single definition of that logic that may be re-used by other applications. However, this benefit is oftn exaggerated as you could also isolate that logic in a library that you share across applications. Of course, if the applications are in different languages, then there is true benefit in stored procedures, as it is probably easier to call a procedure through your language's db interface than to link to a library written in another language.
• If you are interested in RDBMS portability, then stored procedures are likely to become one of your biggest problems. Core featres of all major and minor RDBMS-es are quite similar. The largest differrences can be found in the syntax and available built-in functionality for stored procedures.

Regarding roundtrips:

• If your have many multi-statement transactions, or in general, functions in your application that require multiple SQL statments, then performance can improve if you put those multiple statements inside a stored procedure. The reason is that calling the stored procedure (and possibly returning multiple results from it) is just a single rountrip. With raw SQL, you have (at least) one roundtrip per SQL statement.

Answer 4

I can't see when Ad-Hoc queries would give any benefits. Discussing with a friend this same question we found the following thing in favour of stored procedures (apart from the obvious caching/SQL Injection issues):

1) Code readability: If you have some hairy SQL Code embedded in your application, it becomes much harder to read/understand. It is much simpler to have a good Naming Convention to Stored Procedures that says exactly what it does, instead of a lot of code. It is more less the same principles that we try to use when refactoring.

2) Ability to improve your application without to redeploy: If you need to tweak your logic because of bugs or poor performance, having the SQL Code embedded in your application implies that you need to redeploy it (even if your dataset doesn't change). If you have it in a stored procedure, the only thing you need to redeploy is the procedure. Also, it gives the changes to a DBA to do its magic improving the overall performance of the query by working with the procedure. This would be much harder to do if you're working with the embedded version.

3) Network Traffic: If you're passing a lot of SQL Code around you're increasing the size of your message (or RPC calls) being transmitted over the network, which can lead to poor performance due to requests. Specially if many users to the same calls everytime.

I hope this helps.

Cheers, Wagner.

Answer 5

Ad-hoc queries give you flexibility in your application logic, but you almost always pay a price on performance.

If you are concerned with performance, I'd probably agree with your friend that you should look into stored procs, or some more static form of query, to allow the database to "pre-optimize" the query, or allow the caching layer (if one exists) to potentially cache query results.

If you generate the query on the fly every time, the database will most likely not be able to help you at all with performance.

Answer 6

1. You don't need to write a stored procedure
2. Generally ad-hoc SQL is fast enough. You can use parametrized queries to increase speed.
3. You can compile string based SQL to "compiled" SQL, and then execute that, which is much faster.
4. Typically the performance bottleneck for SQL is the queries not any of the above.