Possible Duplicate:
Inline SQL vs Stored Procedures
I have 100% ad hoc sql through out my application. A buddy of mine recommended that I convert to stored procedures for the extra performance and security. This brought up a question in my mind, besides speed and security is there any other reason to stick with ad hoc sql queries?
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.
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
My answer might be slightly off topic, but anyways:
It could be useful when working with views. Hibernate (that you are not using) for instance, has pretty bad support for views. When I need to query a view with it, I always use raw SQL, since that is the only thing that works.
Portability, when you need to switch to a new SQL server, and don't have access to the old one.
I've worked on a few projects where the original developer wouldn't give access to the server, after he was fired, so we had to re-write many queries ourselves because they were locked up in stored procedures that we didn't have permission to view. If all the queries were in the source code, it would have made it a lot easier.
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.
Truthfully, SQL injection can be prevented by Parameterising your queries (look into ODBCParameters for instance) and your queries can be constructed such that these parameters cannot be SQL injected. For instance...
DECLARE @param varchar(50)
SELECT @param = ?
SELECT * FROM TABLE WHERE NAME = @param
is a safe method of doing internal queries with ODBC parameters. However, there are some advantages to using Stored Procedures:
When all is said and done, its a design decision. Don't take portability into account, you can just have the SQL dev give you the scripts to apply the store procs and run them on installation of the program anyway :)
Hope this helps
There are a couple myths related to this topic that you should disabuse yourself of:
Myth 1: Stored procedures are pre-compiled
http://scarydba.wordpress.com/2009/09/30/pre-compiled-stored-procedures-fact-or-myth/
Myth 2: Ad Hoc SQL queries do not reuse execution plans: http://scarydba.wordpress.com/2009/10/05/ad-hoc-queries-dont-reuse-execution-plans-myth-or-fact/
IMHO procs have the edge when you absolutely need to lock down the database. In these situations, you can use an account that only has rights to execute stored procedures. Additionally, they can provide a layer of abstraction between your app and the database from the DBA perspective.
Likewise, dynamic SQL is better in situations where the query may need to change some and be... well... dynamic. Or if you know you have to port to multiple databases.
Both are just as safe in regards to SQL injection as long as all user inputted values are parameterized.
SQL Server caches the execution plans for ad-hoc queries, so (discounting the time taken by the first call) the two approaches will be identical in terms of speed.
In general, the use of stored procedures means taking a portion of the code needed by your application (the T-SQL queries) and putting it in a place that is not under source control (it can be, but usually isn't) and where it can be altered by others without your knowledge.
Having the queries in a central place like this may be a good thing, depending upon how many different applications need access to the data they represent. I generally find it much easier to keep the queries used by an application resident in the application code itself.
In the mid-1990's, the conventional wisdom said that stored procedures in SQL Server were the way to go in performance-critical situations, and at the time they definitely were. The reasons behind this CW have not been valid for a long time, however.
Update: Also, frequently in debates over the viability of stored procedures, the need to prevent SQL injection is invoked in defense of procs. Surely, no one in their right mind thinks that assembling ad hoc queries through string concatenation is the correct thing to do (although this will only expose you to a SQL injection attack if you're concatenating user input). Obviously ad hoc queries should be parameterized, not only to prevent the monster-under-the-bed of a sql injection attack, but also just to make your life as a programmer generally easier (unless you enjoy having to figure out when to use single quotes around your values).
Update 2: I have done more research. Based on this MSDN white paper, it appears that the answer depends on what you mean by "ad-hoc" with your queries, exactly. For example, a simple query like this:
SELECT ID, DESC FROM tblSTUFF WHERE ITEM_COUNT > 5
... will have its execution plan cached. Moreover, because the query does not contain certain disqualifying elements (like nearly anything other than a simple SELECT from one table), SQL Server will actually "auto-parameterize" the query and replace the literal constant "5" with a parameter, and cache the execution plan for the parameterized version. This means that if you then execute this ad-hoc query:
SELECT ID, DESC FROM tblSTUFF WHERE ITEM_COUNT > 23
... it will be able to use the cached execution plan.
Unfortunately, the list of disqualifying query elements for auto-parameterization is long (for example, forget about using DISTINCT, TOP, UNION, GROUP BY, OR etc.), so you really cannot count on this for performance.
If you do have a "super complex" query that won't be auto-parameterized, like:
SELECT ID, DESC FROM tblSTUFF WHERE ITEM_COUNT > 5 OR ITEM_COUNT < 23
... it will still be cached by the exact text of the query, so if your application calls this query with the same literal "hard-coded" values repeatedly, each query after the first will re-use the cached execution plan (and thus be as fast as a stored proc).
If the literal values change (based on user actions, for example, like filtering or sorting viewed data), then the queries will not benefit from caching (except occasionally when they accidentally match a recent query exactly).
The way to benefit from caching with "ad-hoc" queries is to parameterize them. Creating a query on the fly in C# like this:
int itemCount = 5;
string query = "DELETE FROM tblSTUFF WHERE ITEM_COUNT > " +
itemCount.ToString();
is incorrect. The correct way (using ADO.Net) would be something like this:
using (SqlConnection conn = new SqlConnection(connStr))
{
SqlCommand com = new SqlCommand(conn);
com.CommandType = CommandType.Text;
com.CommandText =
"DELETE FROM tblSTUFF WHERE ITEM_COUNT > @ITEM_COUNT";
int itemCount = 5;
com.Parameters.AddWithValue("@ITEM_COUNT", itemCount);
com.Prepare();
com.ExecuteNonQuery();
}
The query contains no literals and is already fully parameterized, so subsequent queries using the identical parameterized statement would use the cached plan (even if called with different parameter values). Note that the code here is virtually the same as the code you would use for calling a stored procedure anyway (the only difference being the CommandType and the CommandText), so it somewhat comes down to where you want the text of that query to "live" (in your application code or in a stored procedure).
Finally, if by "ad-hoc" queries you mean you're dynamically constructing queries with different columns, tables, filtering parameters and whatnot, like maybe these:
SELECT ID, DESC FROM tblSTUFF WHERE ITEM_COUNT > 5
SELECT ID, FIRSTNAME, LASTNAME FROM tblPEEPS
WHERE AGE >= 18 AND LASTNAME LIKE '%What the`
SELECT ID, FIRSTNAME, LASTNAME FROM tblPEEPS
WHERE AGE >= 18 AND LASTNAME LIKE '%What the`
ORDER BY LASTNAME DESC
... then you pretty much can't do this with stored procedures (without the EXEC hack which is not to be spoken of in polite society), so the point is mute.
Update 3: Here is the only really good performance-related reason (that I can think of, anyway) for using a stored procedure. If your query is a long-running one where the process of compiling the execution plan takes significantly longer than the actual execution, and the query is only called infrequently (like a monthly report, for example), then putting it in a stored procedure might make SQL Server keep the compiled plan in the cache long enough for it to still be around next month. Beats me if that's true or not, though.
I have 100% ad hoc sql through out my application. A buddy of mine recommended that I convert to stored procedures for the extra performance and security.
I would not worry about performance until there are actual pain points. For example, someone is using your application and complains that it's slow. Until you reach that point, your time is best spend improving your application.
In security, you have to balance effort versus risk. If your site doesn't store anything of value, even SQL Injection is a perfectly acceptable risk, as proven by a great number of web sites out there :)
It may depend on who else is using the db. If only one application uses the db, then parametrized queries have the advantage of sitting in the source.
If other applications use the db, then the dba should put common stored procedures in the db.
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.
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.
Regarding roundtrips:
One advantage of stored procedures is that data does not have to be transferred over the network for intermediate calculations. If a lot of calculation results in a single value, then the stored procedure is going to be faster.
There is no "right" answer. It depends on each situation.
Did anyone mention this? Stored procedures typically return every field and it's unfeasible to create one for each variation of fields that you want. Ad-hoc lets you specify only those you want. However, if you are using any sort of entities (custom objects, EF, etc.) you'll probably be returning all fields anyway.
Speaking from my experience, I would put an advantageous point for each method.
Point for Ad-Hoc SQL:
There is a case when Ad-Hoc SQL is less painful (initially), which involves large (and dynamic) range of search parameters. Say, for example, you have an Account Search, and a companion Advanced Account Search, which contains 3 times more parameters. Some of the fields are easy (Account #); others may be very painful (a substring search on Address Line 1!) And for the worst, most of the parameters are not required.
This makes performance tuning not trivial. In this case, having so many combinations of parameters, caching of execution plan (my experience is on MS SQL) will backfire. The execution plan for, say, providing Account # and Salesman # only, will potentially be very bad for another set of search, providing Address search and the brands they carry. Ad-Hoc SQL will have the side effect of recompiling based on different sets of parameters provided, thus getting around the execution plan caching problem.
Of course, the above can be done by stored procedure as well, but in order to get around the execution plan caching problem, you will have to launch the recompile command within the stored procedure. One can also argue that the dynamic SQL construction can be put within the stored procedure, but this is just moving the Ad-Hoc SQL into another place; still Ad-Hoc SQL.
Point for Stored Procedure:
One can consider Stored Procedures as API. If you have worked on enterprise environments, chances are there will be different applications doing exactly the same thing. For example, the event table may be inserted from different softwares, including Accounting, Sales, Auditing, Customer Relationship Management, etc. These programs may not be maintained by the same group of people (e.g. different subdivisions), but they will ultimately having access to the same underlying database.
In this case, it would be a source code management nightmare for using Ad-Hoc SQL, because this would result in multiple versions of Ad-Hoc SQL performing the same functionality, in which every version may have different side effects. I am currently dealing with this situation, and it is not fun. Stored Procedures in this case can be reused, thus having a central management of database codes.
There probably won't be a performance benefit, but for maintainability you might want to look into using something like LINQ2SQL, so that you don't have syntax errors in your SQL.