THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Kevin Kline

LINQ: Enabling or Entangling?

There’s been a lot of positive press for LINQ, such as the article about LINQ by Mike Otey at  You can also find lots of glowing reviews and info about LINQ by Troy Magennis at


I've been trying to figure out exactly how I feel about LINQ, along with several other developer-oriented technologies that Microsoft has launched over the years, such as CLR.  Ambivalence is the emotion that bubbles to the top most frequently.  It's pretty obvious to me that Transact-SQL is the red-headed step child within Microsoft's overall ranking of languages. 


One of the big problems I have with Microsoft’s approach is that it’s too tactical.  Every 2-3 years, Microsoft launches TNBT (“the next big thing”).  TNBT will make our code better, our developers faster, our applications more efficient, walk your dog, wash your cat, tie your shoelaces, end world hunger, and otherwise make everything better.  The only problem is that TNBT is usually put together by one subteam of a major group, such as the languages group inside of the SQL Server development team.  These small teams, while brilliant, often don’t get the top-down support to institute a major sweeping change to how things work.  Consequently, we get a feature set that, while useful, doesn’t give us everything we need to sweep out the old and introduce the new.


This sort of 50% solution manifests itself in a lot of different ways, usually by making some aspects of the development process better and other aspects worse.   My friend and fellow SQL Server MVP Andrew Kelly has an interesting blog post and subsequent comments at which strongly illustrates this idea.  Basically, (most) developers still don’t understand the basics of building an efficient database solution.  The thing that most improves database applications is proper planning and design.  But tools like LINQ and the entity framework most obviously help developers speed up development process, in effect encouraging even less planning and design than ever before.  A recipe for disaster?  Almost certainly.


I hate to think that the language that I’m best at is the most likely to lose overall support.  On the other hand, I’d love to get in on TNBT (“the next big thing”) while it’s still in its genesis.  However, figuring out what, exactly, they are planning to replace Transact-SQL with is yet to be seen since each new offering is, IMO, sadly lacking in value. 


As an administrator, I’m putting a lot of eggs into the PowerShell basket – the first major scripting/programming language in many years that I’m taking the time to get really good at.  However, I still don’t think we’ve hit TNBT in development languages and we probably won’t until Microsoft takes the time to convene a high-powered team composed of members from both the SQL Server and Visual Studio organizations.


Published Tuesday, December 23, 2008 2:49 PM by KKline
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



The Bit Bucket (Greg Low) said:

Kevin Kline recently posted , wondering about the directions for LINQ. When people refer to LINQ, they're

December 23, 2008 5:33 PM

Armando Prato said:

I think the fundamental problem is that MS is trying too hard to make database programming "easy". Like you said, there's no substitute for proper design. In the rush to build a pretty application, the proper foundation is rarely laid down.  The database is more than a place to just stick data.  The database is your foundation and its data is the most critical component of your company.

December 23, 2008 8:45 PM

aspiringgeek said:

I missed Andy's excellent post until you pointed me to it:

You're both right on.  Making things too easy isn't a good thing.  Nicely done.

December 24, 2008 10:25 AM

Steve Dassin said:


CS Techcast 55: Database Trends

Billy Bosworth, SQL Server VP & GM of Quest Software.

"Lets look at the MS vision of the future when you talk about their data access layers. They're really 'discouraging' any continued paradigm of using sequel(sql) inside an application. They want you to use Linq, they want you to use all their object relational

mapping layers and they want you to be able to write in terms of object classes and not necessarily in thinking in terms of rows and columns and tables."

This is an accurate assessment of where sql is in the mix of application development. It's been subtracted and as far as MS is concerned less is more. There is no longer any motivation from MS for developers to model business problems relationally. This is one of the greatest snuff jobs in IT history. MS is redefining the meaning of sql, S(queezing)Q(ueries)L(ifeless). And what has been the response of the sql community to this historic vote of no confidence? From the evidence, far too little and probably far too late. If the MS sql community wants to make itself relevant to MS application development they better find some strategists and

politicans among the geeks:)

>Making things too easy isn't a good thing.

Besides being a shallow and trite summation of what MS is trying to do, has anyone considered the flip side of the coin? That sql has forever had the market cornered on obfuscation and counterintuitiveness as far as developers are concerned? Developers would perceive anything compared to sql as 'easier':)

December 28, 2008 2:27 PM

Armando Prato said:

The SQL language has been around for years in albeit various flavors. Now compare this to the application language "flavors of the month" that have come (and gone in some cases) such as Visual BASIC, C, C++, Visual C++, Powerbuilder, Java, Visual J++ (remember that one?), and now the .Net languages.  If anything, the SQL language has been relatively stable when compared to application programming languages despite its "counterintuitiveness".  

As a database professional, I have seen some pretty applications with absolutely HORRENDOUS data models which have led to a myriad db issues (i.e. excessive blocking, deadlocks, etc).  Most times it's not the database per se that is at fault. It's the lack of design which was not thought out or neglected altogether in the rush to build a functioning application.  LINQ, in my opinion, does not help this situation at all.

If one is going to take the time to learn the next application language "flavor of the month", why not take some time to learn and understand what makes for a good database design?  I'll never understand why a lot of developers consider the database as a "necessary evil" as opposed to what it truly is:  A partner in the building of a scalable, robust application.

December 28, 2008 7:55 PM

Steve Mitcham said:

Don't make the mistake of thinking that LINQ is limited to Entity Frameworks, or LINQ to SQL.  I've been using LINQ to objects and custom providers for LINQ very successfully in my projects that have no DAL and it is simplifying and clarifying our codebase by leaps and bounds.

December 29, 2008 11:47 PM

Leave a Comment


About KKline

Kevin Kline is a well-known database industry expert, author, and speaker. Kevin is a long-time Microsoft MVP and was one of the founders of PASS,

This Blog



Privacy Statement