Stored Procedures vs Code in Database Query

Question

What are the performance differences between accessing a database to query using ASP.NET Code behind against using SQL Stored Procedure

For ease of use, coding the query is easier, especially when coming to maintenance and changes.

However, a stored procedure is compiled in a database and run by the database.

Which one is more efficient, better to use?

Answer 1

SQL Server caches the execution plan of any query, SPROC or not. There is virtually no difference here. Basically, you save sending the query text over the network when using an sproc, nothing more. Source: http://msdn.microsoft.com/en-us/library/ms181055.aspx

Without and special reason being present, do what ever is more convenient to you.

The other answers suggesting generally better performance for sprocs are not true.

Answer 2

As long as it is a database centric query then the stored procedure will in most times be the faster choice (Performance).

But it is harder to maintain because its not in your regular source bundle.

"Better to use" depends on the requirements. If its okay when the query is a tad slower (like 1 ms VS 3 ms) then keep your code together and have it in ASP. If performance is the thing you want put it in the Database.

I put most of my queries in the code and only the ones that NEED the performance in the database.

Also it depends on the Database System used, of course.

Answer 3

Your question is very incomplete as to what you are actually comparing.

Whether the SQL code is in a stored procedure or a full-blown inline SQL statement submitted from the client usually makes little difference (assuming proper parameterization and the SQL being non-pathological) to performance. It can make a large difference in the security architecture and access required to be given to base tables or views instead of execution rights on procedures. Stored procs encourage parameterization as a requirement, but parameterization is also possible with inline SQL.

If you are talking about performing logic against sets returned from the database versus doing the work in the database, this can go both ways - it depends upon the type of operation, the type of indexing, the bandwidth between client and database and number of requests needed to be serviced.

Usually, I'd look first at doing it in the database to keep the join/looping logic abstracted from the client and reduce data on the wire (both columns and rows) and present a simple data set API to the client, but IT DEPENDS.

Answer 4

This is an "it depends" question.
Presuming this is SQL Server 2008R2 or higher Standard or Enterprise edition, stored procedures will cache differently than a TSQL statement. Complex T-SQL statements will almost always perform worse than a stored procedure due to multiple things such as parameterization, code compilation, parameter sniffing, and various other optimizations. In general, I prefer stored procedures as they are MUCH easier to optimize. Plus you can change a stored proceudre without re-compiling and re-deploying any code. And optimizations (such as "optimize for unknown" or "with recompile" can be applied to a stored procedure when parameter values vary drastically) can be applied to a stored procedure and un-done without end users even noticing (well, except for a performance change).

A stored procedure will always end up in the plan cache after a single run and will never be considered an ad-hoc query. Ad-hoc queries, depending on SQL settings, may or may not be stored in the plan cache. Plus adding or removing a character (presuming it is not parameterized) will cause SQL Server to build a new plan and building new plans is a slow operation.

TL;DR - preusming SQL Server 2008R2 or higher Standard/Enterprise; for simple queries, you will notice no difference. For complex queries, stored procedure (if written properly) will almost always out perform T-SQL. Stored procedures are easier to optimize at a later date as well.

Edit - added in SQL version. I am uncertain about older SQL versions.