3 ms·

There is a certain level of functionality available in all relational databases...LINQ to SQL has been designed to be isomorphic to that functionality. The resu

There is a certain level of functionality available in all relational databases...LINQ to SQL has been designed to be isomorphic to that functionality. The result of that (plus the very powerful reflection classes in .NET) means that the only problem here is that Microsoft hasn't optimized the expression tree to SQL output as much as possible. After another update or two to the .NET framework, the performance should be virtually identical; it may possibly be even better with LINQ to SQL since it may 'think' to optimize queries in ways that you wouldn't think to. On a side note, the author also neglects to mention that LINQ to SQL is a great way to make your code more portable to other platforms (Mono) or other databases (MySQL, PostgreSQL, etc.) so that you don't have to learn the intricacies of each databases' SQL syntax.

batasrki 17y ago
Only one problem there. Microsoft has pretty much EOL'd LINQ-to-SQL in favour of Entity Framework. So, the performance improvements and code improvements that you speak of will never get done.
logicalmind 17y ago
Linq to SQL produces expression trees. These expression trees are interpreted by the query provider. In the case of Linq to SQL the query provider produces SQL for the SQL Server dialect. The SQL can be optimized. This SQL is sent to SQL Server which then parses and optimizes the execution plan for the SQL (or not if it is already in the procedure cache). Are you saying that the Linq expression to SQL optimization will replace the SQL Server SQL plan optimization? The gory details of producing a Linq query provider are covered in this series of blog posts: http://blogs.msdn.com/mattwar/pages/linq-links.aspx http://blogs.msdn.com/mattwar/pages/linq-links.aspx
- profquail 17y ago
  No, I'm not saying that Linq to SQL will replace the SQL Server plan optimization; I'm merely pointing out that a well-optimized (and perhaps dynamic, using reflection) query provider could probably generate better, more efficient SQL queries than 99% of developers in 99% of use cases. You might miss out on some potential optimizations simply because you're trying to get the code working right instead of spending hours to shave a few milliseconds off of your query's execution time (plus, nobody's perfect!)

batasrki 17y ago

Only one problem there. Microsoft has pretty much EOL'd LINQ-to-SQL in favour of Entity Framework. So, the performance improvements and code improvements that you speak of will never get done.

logicalmind 17y ago

Linq to SQL produces expression trees. These expression trees are interpreted by the query provider. In the case of Linq to SQL the query provider produces SQL for the SQL Server dialect. The SQL can be optimized. This SQL is sent to SQL Server which then parses and optimizes the execution plan for the SQL (or not if it is already in the procedure cache). Are you saying that the Linq expression to SQL optimization will replace the SQL Server SQL plan optimization? The gory details of producing a Linq query provider are covered in this series of blog posts: http://blogs.msdn.com/mattwar/pages/linq-links.aspx http://blogs.msdn.com/mattwar/pages/linq-links.aspx

profquail 17y ago
No, I'm not saying that Linq to SQL will replace the SQL Server plan optimization; I'm merely pointing out that a well-optimized (and perhaps dynamic, using reflection) query provider could probably generate better, more efficient SQL queries than 99% of developers in 99% of use cases. You might miss out on some potential optimizations simply because you're trying to get the code working right instead of spending hours to shave a few milliseconds off of your query's execution time (plus, nobody's perfect!)