Supposedly, microsoft says that we should all be using Entity Framework, using LINQ (to Entities?) as the query language.
If LINQ as a query language is an improvement over SQL, then I say the database should support it natively instead of LINQ being translated into SQL.
For backward compatability, they’d probably want to support ancient old SQL, too? Given that this wouldn’t exactly be a minor enhancement, I woon’t hold my breath. But if we are thinking ideally and very long term, why not?
Am I nuts to think that this would be a good thing if it were practical? I’m expecting “yes” as a likely answer and several votes to close.
SQL is tightly bound to the relational data model (projections, joins etc), whereas LINQ is a more generalized way to perform data manipulation that just abstracts your query.
On the other side LINQ operates directly on the .Net types and uses their methods and properties, whereas SQL data types are (except for xml and geography/geometry) mostly primitive data types not supporting any kind of OOP.
This explains why there are many queries that cannot be directly translated from LINQ to SQL and native support for LINQ won’t improve the situation.
However, writing a parser for supported LINQ queries that would directly transform a LINQ query into a query plan would be an interesting option as an alternative for classic SQL, for LINQ is designed for better IntelliSense support in mind.