I am using sql server and winforms for my application. data would be inserted every minute into the database tables by pressing a button on a Form.
for this, I am using the INSERT query.
But if I create a procedure and include the same insert query in it, then would it be more efficient, what would be the difference then?
Using stored procedures is more secure
A stored procedure would generally be quicker as the query plan is stored and does not need to be created for each call. If this is a simple insert the difference would be minimal.
A stored procedure can be run with execute permissions which is more secure than giving insert permissions to the user.
It depends on what you mean by 'efficient'.
Execution time - if you're only saving to the database only every couple of seconds then any speed difference between SPs and INSERT is most likely insignificant. If the volume is especially high you would probably set up something like a command queue on the server before fine-tuning at this level.
Development time
using INSERT means you can write your SQL directly in your codebase (in a repository or similar). I've seen that described as poor design, but I think that as long as you have integration tests around the query there's no real problem
Stored Procedures can be more difficult to maintain - you need to have a plan to deploy the new SP to the database. Benefits are that you can implement finer-grained security on the database itself (as #b-rain and #mark_s have said) and it is easy to decide between INSERT and UPDATE within the SP, whereas to do the same in code means making certain assumptions.
Personally (at the moment) I use inline SQL for querying and deleting, and stored procedures for inserting. I have a script and a set of migration files that I can run against the production database to deploy table and SP changes, which seems to work pretty well. I also have integration tests around both the inline SQL and the SP calls. If you go for inline SQL you definitely should use parameterised queries, it helps against SQL injection attacks and it is also easier to read and program.
If your DBA is even allowing you to do this without a stored procedure I'd be very suspicious...
Related
I am using SQL Server 2005 database and my application is in ASP.NET MVC4.
The application's business logic is bit complex, containing multiple table joins and search conditions. In extreme conditions I need to join around 10 tables to fetch the data required for a single grid.
I would like to know whether I should use SPs or Linq to SQL application code to maximize my application performance.
SQL Server basically goes through these steps to execute any query (stored procedure call or ad-hoc SQL statement):
syntactically check the query
if it's okay - it checks the plan cache to see if it already has an execution plan for that query
if there is an execution plan - that plan is (re-)used and the query executed
if there is no plan yet, an execution plan is determined
that plan is stored into the plan cache for later reuse
the query is executed
The point is: ad-hoc SQL and stored procedures are treated no differently.
If an ad-hoc SQL query is properly using parameters - as it should anyway, to prevent SQL injection attacks - its performance characteristics are no different and most definitely no worse than executing a stored procedure.
Stored procedure have other benefits (no need to grant users direct table access, for instance), but in terms of performance, using properly parametrized ad-hoc SQL queries is just as efficient as using stored procedures.
Update: using stored procedures over non-parametrized queries is better for two main reasons:
since each non-parametrized query is a new, different query to SQL Server, it has to go through all the steps of determining the execution plan, for each query (thus wasting time - and also wasting plan cache space, since storing the execution plan into plan cache doesn't really help in the end, since that particular query will probably not be executed again)
non-parametrized queries are at risk of SQL injection attack and should be avoided at all costs
You are typically going to find faster performance with stored procedures because the stored procedures will re-use execution plans when possible. Linq queries essentially become ad-hoc queries against the database that without caching are processed as a new request each time.
I have a .NET application that works against a SQL Server. This app gets data from a remote third party API, and I need to insert that data to my database in a transaction.
First I delete all existing data from the tables, then I insert each row of data that I get from the API.
I wrote a stored procedure that accepts parameters and does the insert. then I call that stored procedure in a loop with a transaction from .NET.
I'm guessing there's a smarter way to do this?
Thanks
If you're doing thousands or maybe even tens of thousands you can probably do best with table valued parameters.
If you're doing more than that then you should probably look at doing the dedicated SQL server bulk insert feature. That might not work great transactionally if I remember correctly.
Either way truncate is way faster than delete.
What I've done in the past to avoid needing transactions is create two tables, and use another for deciding which is the active one. That way you always have a table with valid data and no write locks.
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?
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.
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.
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.
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.
Often times, I find myself needing to send a user updated collection of records to a stored procedure. For example, lets say there is a contacts table in the database. On the front end, I display lets say 10 contact records for the user to edit. User makes his changes and hits save.
At that point, I can either call my upsertContact stored procedure 10 times with the user modified data in a loop, or send an XML formatted <contact><firstname>name</firstname><lastname>lname</lastname></contact> with all 10 together to the stored procedure. I always end up doing xml.
Is there any better way to accomplish this. Is the xml method going to break if there are large number of records due to size. If so, how do people achieve this kind of functionality?
FYI, it is usually not just a direct table update so I have not looked into sqldatasource.
Change: Based on the request, the version so far has been SQL 2005, but we are upgrading to 2008 now. So, any new features are welcome. Thanks.
Update : based on this article and the feedback below, i think Table Valued Parameters are the best approach to choose. Also the new merge functionality of sql 2008 is really cool with TVP.
What version of SQL Server? You can use table-valued parameters in SQL Server 2008+ ... they are very powerful even though they are read-only and are going to be less hassle than XML and less trouble than converting to ORM (IMHO). Hit up the following resources:
MSDN : Table-Valued Parameters:
http://msdn.microsoft.com/en-us/library/bb510489%28SQL.100%29.aspx
Erland Sommarskog's Arrays and Lists in SQL Server 2008 / Table-Valued Parameters:
http://www.sommarskog.se/arrays-in-sql-2008.html#TVP_in_TSQL
I would think directly manipulating XML in the database would be more trouble than it is worth to go that route; I would suggest instead making each call separate like you suggest; 10 calls to save each contact.
There are benefits to that approach and drawbacks; obviously, you're having to create the database connection. However, you could simply queue up a bunch of commands to send on one connection.
The Sql Server XML datatype is the same as a VARCHAR(MAX) so it would take a really large changeset to cause it to break.
I have used a similar method in the past when saving XML requests and responses and found no issues with it. Not sure if it's the "best" solution, but "best" is always relative.
It sounds like you could use an Object-Relational-Management(ORM) solution like NHibernate or the Entity Framework. These solutions provide you with the ability to make changes to objects, and have the changes propagated to the database by the ORM provider. This makes them much more flexible than issuing your own sql statements to the database. They also make optimizations like sending all changes in a single transaction over a single connection.
I'm using SQL Server 2005. I'm looking at opening a SQL connection, looping though a collection and running an update query (stored procedure or parameterized query) with the data from the collection item, then closing the connection.
Which is going to give me better performance and why?
In recent versions of SQL server, execution plans are cached for stored procedures and parametrized queries. The query will have a one time cost to create the execution plan, but this will be very minor and lost in the overhead of even a few calls.
From a performance perspective they will be almost identical.
The exception to this, is if you are doing recursive or nested queries (for each row in query 1, execute query 2), where the round trips between the client and server will add up. In this case, a proc will be much better.
Many companies still have "Everything as a proc" rules, but this is usually due to control of the database and not performance related. As LINQ grows in popularity, this may lessen.
If your application has a single (or few) points of deployment, then use whichever you prefer. On the other hand, if you are deploying to many many installations, then stored procs can in some (but not all) cases allow you to update database functionality without redeploying the client code.
It is difficult to say with certainty as there are a number of factors that can effect performance. In theory the Stored Procedure method should be faster.
There is another solution where you can pass XML to the stored procedure so you don’t have to call it multiple times. Assuming you can and know how to serialize your object into XML. Then you can use Xquery, Open XML or sp_XML_preparedocument to retrieve your data in a set based manner from the XML and perform the update statement.
This can often turn into a religious debate between programmers and DBAs. Many programmers tend to like the prepared statement approach as it allows them complete control over the query that is being executed while DBAs like the stored procedure approach for the same reason. If you don't have that defined line between developer and DBA in your company and you dabble in both development and DBA roles then I would probably lean more toward the stored procedure route because if you need to make slight changes to the query in the future to fine tune performance or fix bugs then you don't have to recompile and redeploy your application.
Stored Procedures are usually the way to go. That said it also depends on how well your proc is written. Try running an Execution Plan on your Stored Procedure to make sure you're getting the best bang for your buck. Additionally using a Stored Procedure is usually the more secure way to go as well as the best performance on your server, provided the SQL instance is not on the same box as your code. When you use the stored procedure you put the load of the work on the SQL box, which will have optimized the query for you in the stored procedure.
Using a direct query or a stored procedure doesn't differ much in performance (if any), but if you are running the same query over and over with different data you should definitely use parameters.
Use the Prepare method to ensure that the same execution plan is reused:
Create the SqlCommand object with the query/procedure.
Create SqlParameter objects with specified data types but without values, and add them to the Parameters collection of the command.
Call the Prepare method on the command object.
Loop through the data just setting the parameter values and execute the command.
Usually stored procedures, because the server can pre-optimize the execution plan. Though well-written parameterized query is better than an over-general stored procedure.