The Inquisitive Coder - Davy Brion’s Blog

How many developers do you know who can write solid SQL queries? Practically every developer knows SQL, but there aren’t too many who know how to use it well. Now don’t get me wrong, i am by no means a SQL guru… but i like to think i can hold my own when it comes to writing ‘good’ queries. With the advent of querying techniques that shield you from directly using SQL (like the LINQ syntax, or NHibernate’s Criteria) the number of developers with solid SQL knowledge will probably only get smaller and smaller in the coming years. I wonder if in 5 years time, developers with good SQL skills will be as rare as politicians that don’t take money, athletes that don’t use performance enhancing drugs, doctors who care about your health instead of their wallet, gangsta rappers who actually used to be ‘gangsta’, single women that don’t… well, i’m sure you catch my drift.

Pretty soon, most .NET developers will be using nothing but LINQ statements to query their databases. Obviously, a part of the problem will shift from lousy SQL statements to lousy LINQ statements. That’s pretty much unavoidable, given the ratio of ‘bad’ developers out there. But the productivity gains from using LINQ (or Criteria) over directly using SQL will probably become more and more important as time goes on. Not to mention the fact that LINQ is ’sexy’ and will be pushed heavily by Microsoft.

Would that actually be a bad thing though? I kinda think the situation is similar to the shift we’ve seen over the years in programming languages. We used to write code in assembly language. Well, ‘we’ didn’t, but the poor souls who were in this industry before us did. Then people moved to higher level languages (like C) for the increased productivity. Fast-forward a couple of years and people moved to development platforms where the actual code would be compiled to machine code ‘just-in-time’, at runtime even! Oh, the horrors!

In each and every one of those shifts, there were developers who said “i don’t care, my hand-written code is definitely gonna outperform that”. And at the beginning of those shifts, this was probably true for a lot of developers. But as time went on, the newer technologies pretty much always ‘won’ because of the productivity gains. Even if they were slower in direct comparisons. Then again, those technologies evolve as well and they usually get faster along the way. The runtime performance of current Java byte code is a lot better than it was in the first 3 years that Java was around. I’m not sure if the .NET runtime has actually gotten faster in the past couple of years, but then again, it probably picked up on a lot of lessons learned in the Java world before .NET was released.

One thing that has happened consistently is that compilers have always gotten better. Well, they’ve always gotten better at optimizing the code they generate. This leads to situations where the same code actually runs better when it’s compiled with newer versions of a compiler (well, if it still compiles…). Obviously, this isn’t true for all code, but it usually is true for certain statements, or certain frequently-used bad-performing techniques (string concatenation for instance).

I wouldn’t be surprised to see the same thing happening with LINQ providers (or other SQL querying abstractions for that matter). The SQL that is generated by them is pretty good already. And it’s never gonna get worse… they will always become ’smarter’ and they will generate better SQL statements in future versions. When that happens, we all benefit from that.

Sure, there will always be die hard SQL fans who keep writing their own SQL queries and there will always be edge-cases where hand-written SQL queries will be better than those generated by higher level libraries. Especially if those SQL queries were written by Disco Stu. I mean SQL Ben (laugh Ben, it’s just a joke ;)). But i do believe that will only be true in edge-cases.