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

Answer 1

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.

Answer 2

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 :)

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.