score:2

Accepted answer

in my experience the overhead is minimal, provided that the person writing the queries knows what he/she is doing, and take the usual precautions to ensure the generated queries are optimal, that the necessary indexes are in place etc etc. in other words, the database impact should be the same; there is a minimal but usually negligible overhead on the app side.

that said... there is one exception to this; if a single query generates multiple aggregates the l2s provider translates it to a large query with one sub-query per aggregate. for a large table this can have a significant i/o impact as the db i/o cost for the query grows by magnitudes for each new aggregate in the query.

the workaround for that is of course to move the aggregates to stored proc or view. matt warren has some sample code for an alternative query provider that translate that kind of queries in a more efficient way.

resources:

https://connect.microsoft.com/visualstudio/feedback/viewfeedback.aspx?feedbackid=334211

http://blogs.msdn.com/mattwar/archive/2008/07/08/linq-building-an-iqueryable-provider-part-x.aspx

score:2

thanks stu. bottom line seems to be that linq to sql probably doesn't have a significant database performance overhead with the newer versions if you are able to use a compiled select, and the slower functions of updating are likely to be faster unless you have a really sharp expert doing most of the coding.


Related Query

More Query from same tag