Linq over Stored Procedures

Question

What are some pros and cons of using linq over stored procedures?

Answer 1

There are a few things I wanted to add to the discussion:

• Linq is less likely to hit a cached execution plan in SQL Server than a stored procedure. While compilation of basic select statements is light, in more complicated queries compilation can be quite expensive. (At lot of factors go into making this statement true/false for your situation, but that's probably for a different post).

• If you have skewed data recompilation may actually be a benefit prevent odd index use decisions by SQL. Think select * FROM Person where LastName = @Letter First pass where @Letter='Z' (lets say 0.25% of total people) versus @Letter='S' (6.00% of total people) can result in wildly different execution plans.

• Linq is effectively reintroducing ad hoc sql into our code. Granted its through a layer of abstraction and in a new language, but no longer am I calling exec GetOrders @DateStart=@now @DayRange=7 instead I'm writing out my table name, where clause, and order by.

• Tracking non-performant SQL statements back to the code that generated the statements is more diffcult than with SP's. In a high volume environment SQL profiler is often run on a regular basis to find non-performant queries (high CPU, reads, or duration). Since Linq abstracts the text it generates it becomes tough to trace the sql back to a specific location in the code, particularly in larger applications.

• As a side note, when necessary Linq can call a specific stored procedure rather than generating it's own SQL. See this Scott Gu article.