Is LINQ the New SQL More Readers Respond

If SQL Server had such power to understand LINQ natively, really would increase LINQ performance and popularity as well to the developer like me.

Another reason to know SQL is when analyzing the SQL produced by the code. i.e. some complex LINQ statements are notorious for producing horrid SQL queries and you need the ability to look at what is being sent to the DB through the Log or via SQL profiler – but you would only do this if something like performance with the query became an issue.

Another issue is that some frameworks, like EF, have multiple layers of processing that can bog down performance and you might want to either move the query to a stored proc, drop down to ADO.NET and use a DataReader to get the fast firehose, or some other technique for speeding up the operation.

Generally, these alternatives are extreme and you would only need them if the requirements of the application dictated max performance, but in normal data editing operations performance is more than sufficient and you can take advantage of the productivity gains of LINQ on top of the persistence framework.

As a database “guy”: I like LINQ for what it is; a way for application developers to use their data in an object oriented manner; the database engine should remain true to what it is for, which is data storage. Having a language dedicated/specific to the database engine means versatility for the DB engine. It also means that the people responsible for the maintenance of the database engine (DBAs) have a language they can learn for all sorts of non-development tasks. DBAs wouldn’t be very successful using LINQ to manage SQL engine specifics. Plus, non-LINQ platform developers can still use T-SQL for all of their needs.

Now, if you’re just saying that you want to add native support for LINQ to the database engine; I could see how that may seem beneficial. But really, wouldn’t the product team just be adding an interpreter to the engine? So, in a way, just one more thing that can break? To me, that just takes their time away from building (and optimizing) better data storage technology. If anything, I could see the usefulness of taking the time to make LINQ produce better T-SQL; but LINQ should stay where it is in terms of its platform.

If you have some difficult services your database is going to guarantee which aren’t as simple as declarative referential integrity or doable with triggers, you might have to use procs anyway, and then you still might worry about tables which now have read for LINQ purposes but not write since you can’t ensure database integrity if you let people write to those tables instead of going through the approved proc.

Refactor your tables and cause some views to no longer be possible (perhaps an inline table-valued function is now required since you’ve decided to parameterize something), and all of a sudden you’ve introduced some bad coupling.

With a proc with a known interface and results, you can determine more easily the scope of a change. And it is possible to inventory the public interface to the database and understand which clients are calling which functions and how frequently with a bit of instrumentation and/or profiling much more easily than an app which uses LINQ without taking any special measures to help mark the database traffic so you can effectively use the profiler to understand things at a systems level.

The question of whether future developers will need to learn SQL reminds me of when, in 1995, I attended a presentation where they told the assembled designers not to bother learning HTML. Not exactly prophetic. There are tools that take away a lot of the burden with enabling languages, but it will always be true that those tools have limitations that serious developers will consistently need to surpass. So, yes: future developers will still need to learn SQL, even if their Microsoft-funded training courses tell them otherwise.