When Written: Dec 2007
In a previous article one of the issues I raised was the necessity of LINQ ( Language Integrated Query ) as yet another data query language. I very pleased to receive a large number of emails agreeing with my views and a few pointing out the benefits of LINQ over say SQL.
It was interesting that most (but not all) the emails against the idea of LINQ were from people who like myself, have spent quite a number of years in IT, and it might be easy to dismiss these views as the ramblings of ‘grumpy old gITs’ as Mark Saragossi of Octa suggested we could be called. But that would be ignoring the years of real world experience where the need to produce working, reliable code on time is of much more importance than coding with the latest and often untried technology.
Some like Gouranga Gupta of Omnibus-systems suggested that rather than produce a complete new syntax, the array concept could perhaps be extended to include SQL-like functionality. This way we could collect the data into a dataset array and then query it with a language that is well understood. Some of the emails suggested that LINQ has the advantage over SQL in that LINQ is a language feature of VB 9 and C# 3.0 and as such is fully supported by Visual studio 2008, so why can’t SQL be raised to this lofty level?
Another point is that LINQ queries can be as complicated as you like and will be optimised to more efficient SQL by the system. The query optimiser in MSSQL does this now to your existing queries, and anyway most of us have long since learnt what works well as far as queries go, so this is hardly a reason to move to LINQ. Others, like Alex Macklen, outlined some advantages of using LINQ with its type checking, which may help when transferring data from Oracle with its UTF-8 text to a Unicode string, and the ability to reduce round trips to the server by using heterogeneous operation on the data. This is where data that is dynamically read via LINQ into a dataset that is held in memory can then be queried with LINQ again and again.
Similar behaviours occur in MSSQL server with its caching, but there is still a call from your server with the code to the server with the database. Obviously it is important that there are those out there who think about the way technologies should develop and think about new answers to the old and new problems, but the big issue I feel is that, when we have a data query language which is so established that it is not going to go away, then why not extend that language to fit today’s needs rather than create a completely new syntax?
One gets the feeling that the decisions for such things are made by groups of people who are just concerned with what would be ‘cool’ rather than the considerations of the real world. It reminds me of the late beta of Windows that we were told was very near to release code only to find that it didn’t print to network printers! It does make you wonder sometimes what these people are doing!
Article by: Mark Newton
Published in: Mark Newton