We’ve posted a new Expert Spotlight! Joe Anderson (DatabaseMX) has been on Experts Exchange since 2006. Learn more about this database architect, guitar aficionado, and Microsoft MVP.
Using "Stored Procedures" vs. SQL statements within the Applicatin code.
Hi, I'm developing an Application in Visual Studio 2015 - C# that has an SQL database with multiple joined tables. I have the option of creating most, if not all of the SQL queries within the database itself as stored procedures, or within the code of my Application.
My question is - which is a better option? Is it more efficient to create the queries as stored procedures and save them within the database itself, or is it better to keep the query code within the Application code?
My first thought is that calling a stored procedure name like "spGetAllEmployeeNames" to the DB would be less overhead than passing all SQL code to the DB each and every time.
Does anyone have any pros / cons for doing it either way?
Thanks for your guidance,
Fulano
My question is - which is a better option? Is it more efficient to create the queries as stored procedures and save them within the database itself, or is it better to keep the query code within the Application code?
My first thought is that calling a stored procedure name like "spGetAllEmployeeNames" to the DB would be less overhead than passing all SQL code to the DB each and every time.
Does anyone have any pros / cons for doing it either way?
Thanks for your guidance,
Fulano
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Stored Procedures are generally thought to be the more secure and robust method. They can also lead to better execution times as they don't need (re)compilation at each run.
Stored procedures also help with the separation of responsibilities - especially for code reviews. I go, I make this call, then I do this with the data. Versus trying to parse out the sql at the same time.
A lot of times you end up re-using sql code and there's no need to touch multiple places in your application if you can change the stored proc once.
Execution time and cached results help performance.
Stored procs are usually the way to go IMO.
A lot of times you end up re-using sql code and there's no need to touch multiple places in your application if you can change the stored proc once.
Execution time and cached results help performance.
Stored procs are usually the way to go IMO.
I was the kind of guy to put all the queries in my code. I switch my mind a long time ago for a couple of reasons:
-.net code much easier to read
-SPs can be tested relatively easily without the need to run a full application
-SPs can be fixed without having to redeploy the application
-SPs can also be used with ORM tools like EF
-.net code much easier to read
-SPs can be tested relatively easily without the need to run a full application
-SPs can be fixed without having to redeploy the application
-SPs can also be used with ORM tools like EF
one great reason that no one has brought up is that if you use stored procedures, you are free to update your db schema and you could potentially modify your stored procedures and never have to recompile your application.
a downside could be if you have a very bloated organization in which anything that needs to get done has to go through a DB admin and that admin's priorities are not supporting your application.
odds are 99% of the time, stored procedures are the way to go. personally i like to add another layer of abstraction and create a web service that calls my database. so this way your application calls a rest service and it interacts with your database. this way you can add native applications in the future that use the same web service or you can even swap the entire database out for some other data retention technology and all you'd have to do is update the web service.
this separation of concerns also lets you create a web service that returns test data without querying a db leaving you free to develop your application and data layer in parallel.
a downside could be if you have a very bloated organization in which anything that needs to get done has to go through a DB admin and that admin's priorities are not supporting your application.
odds are 99% of the time, stored procedures are the way to go. personally i like to add another layer of abstraction and create a web service that calls my database. so this way your application calls a rest service and it interacts with your database. this way you can add native applications in the future that use the same web service or you can even swap the entire database out for some other data retention technology and all you'd have to do is update the web service.
this separation of concerns also lets you create a web service that returns test data without querying a db leaving you free to develop your application and data layer in parallel.
In addition to the above correct answers having T-SQL in the database is ideal for 'impact analysis', which loosely means 'If I wanted to change/delete/rename table X, where in my code would I also have to change it?'. Searching the database for all instances of X is WAYYYY easier than searching the database plus any number of application / report / ETL package files for any instance of X, in any number of locations they may reside.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial