Why do I need Stored Procedures when I have LINQ to SQL

Question

My understanding of Linq to Sql is it will take my Linq statement and convert it into an equivalent SQL statement.

So

var products = from p in db.Product         


        

Answer 1

I can think of several good reasons for stored procedures:

• When working with bigger tables, it can be hard to generate an efficient query using LINQ to SQL.
• A DBA can analyze and troubleshout stored procedures. But think of what happens when two complicated LINQ operations from different front-ends clash.
• Stored procedures can enforce data integrity. Deny write access on tables, and allow changes only through stored procedure.
• Updating stored procedures is as easy as running ALTER PROCEDURE on a server. If a deployment takes months, and a script minutes, you'll be more flexible with stored procedures.

For a small application that's maintained by one person, stored procedures are probably overkill.

Answer 2

Reason : Large amounts of data to move from one table to another.

Let's say that once in a while you have to archive items from one table to another or do similar things. With LINQ that would mean to retrieve let's say one million rows from table A into the DBMS client and then insert them into table B.

With a stored procedure things work nice, in sets.

Answer 3

Some things can't be done without stored procedures. For instance, at my previous job, there was a stored procedure that return the current value from a row, and incremented it in the same atomic operation such that no two processes every got the same value. I don't remember why this was done instead of using auto-increment, but there was a reason for it.

Answer 4

Security.

I've seen several "security best practice" guidelines which recommend you do all your data access via SP's, and you only grant privileges to execute those SP's.
If a client simply cannot do select or delete on any database tables, the risk may be lower should that client be hacked.

I've never personally worked on a project which worked this way, it always seemed like a giant pain in the backside.

Answer 5

Lots of people have been getting by just fine without them for some time now. If you can do your work securely and efficiently without them, don't feel guilty about going with pure L2S. We're glad to be rid of them @ my shop.

Answer 6

I tend to prefer using stored procedures for several reasons:

1. it makes the security configuration easier (as mentioned by other posters).
2. It provides a clearly defined interface for DB access (although responsibility for this could be shifted into other areas, such as a DAL written in C#
3. I find that the Query Optimizer, in Oracle at least, is able to make more intelligent decisions the more information you give it. This really requires testing with both methods though for your specific scenarios though.
4. Depending on the developers available, you may have some very good SQL coders who will be better at producing efficient queries if they use sprocs.

The downside is that it can be a pain to keep the code that invokes the sprocs in sync with the database if things are evolving rapidly. The points about producing efficient queries could count as premature optimization. At the end of the day, there is no substitute for benchmarking performance under realistic conditions.