LINQ to SQL与存储过程的效率

Question

Hi I'm writing a app which has a search page and does a search on the database.

I'm wondering whether I should do this in linq or a stored procedure.

Is the performance of a stored procedure much better than that of linq to sql?

I'm thinking it would be because in order to write the linq query you need to use the datacontext to access the table on which to query. I'm imagining this in itself means that if the table is big it might become inefficient.

That is if you were using:

context.GetTable<T>();

Can any one advise me here?

Answer 1

There is unlikely to be much difference UNLESS you encounter a situation where the TSQL produced by Linq to SQL is not optimal.

If you want absolute control over the TSQL use a stored procedure.

If speed is critical, benchmark both and also examine the TSQL produced by your Linq to SQL solution.

Also, you should be wary of pulling back entire tables (unless they are small, such as frequently accessed lookup data) across the wire in either solution.

Answer 2

If the speed is so critical to you then you should go ahead and benchmark both options on a reasonable set of data. Technically I would expect the SP to be faster but it might not be that much of a difference.

Answer 3

What does "efficient" mean to you?

I'm working on a website where sub seconds (preferably sub 500ms) is the goal. We're using Linq for search on most of our stuff. The only time we're actually using a SP is when we're using the hierarchyid and other SqlServer data types that don't exist in EF.

Answer 4

GetTable probably isn't going to be that different between the two, as fundamentally it's just SELECT * FROM T. You'll see more significant gains from stored procedures in cases where the query isn't being written very optimally by Linq, or in some very high load situations were caching the execution plan makes a difference.

Benchmarking it is the best answer, but from what it looks like you're doing I don't think the difference is going to amount to much.