In my last column (published in the February e-edition and the March print edition of DBTA), I reviewed the overall coding landscape for SQL Server with special focus on LINQ to SQL, a new technology introduced by Microsoft in late 2008. LINQ to SQL promised to make developers' lives much easier by allowing them to focus on writing programs in their favorite Visual Studio language and letting LINQ to SQL write all the Transact-SQL code. The problem is that LINQ to SQL writes very bad Transact-SQL code.
In this column, I'd like to talk about the ramifications of releasing a product like LINQ to SQL. In some ways, this situation reminds me of the law of unintended consequences. Remember how Chesapeake Bay oystermen saw their haul of oysters drop in the 1980s and 1990s? Because starfish are the oysters' main predators, the oystermen thought chopping them up would eliminate them. Years later, however, everyone learned that starfish regenerate and, by cutting them up, the oystermen were actually creating multitudes more starfish. It feels like a similar sort of unintended consequence is happening each time Microsoft introduces some new, but not fully baked, technology for Transact-SQL and general SQL.
One of my big problems with Microsoft's approach with LINQ is that it is too tactical. Every 2 to 3 years, Microsoft seems to roll out TNBT ("the next big thing"). The promise is always the same. TNBT will make your code better, your developers faster, your applications more efficient, make your coffee, walk your dog, tie your shoelaces and otherwise make life better for everyone. The only problem is that TNBT usually is put together by a single sub-team of a major organization. These small teams, while brilliant, often don't get the top-down support to institute a major paradigm shift, nor do they thoroughly understand both the backend platform and the frontend application. 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 half-way there solution sometimes makes aspects of the development process better, but, often unintentionally makes other aspects worse. For example, what most improves database applications is proper planning and design, not "quick and easy." But tools like LINQ help developers speed up the development process, in effect encouraging even less planning and design than ever before. A recipe for disaster? Usually.
On the other hand, we have Transact-SQL obviously waning. Microsoft hasn't yet found a way to put the final nail into the coffin, but they're obviously, though subtly, planning for it to go. I hate to think the language that is the forte of most DBAs is doomed. However, if Microsoft can strategically develop a new programming language and toolkit that incorporates the good features of Transact-SQL and .NET languages without introducing problems, I'll be the first to jump on the TNBT bandwagon while it's still in its genesis.
My message to Microsoft is this-don't be afraid to build a better product than Transact-SQL, but don't release it as an alternative if it's not excellent. A half-baked alternative to Transact-SQL will not make SQL Server or the development process any better and, very likely, will make things worse.
As an administrator, I'm putting a lot of eggs into the PowerShell basket-the first new and really good scripting/programming language in a long time. However, we haven't seen TNBT in development languages and we won't until Microsoft makes it a true strategic priority and convenes a team from both the SQL Server and Visual Studio organizations who understand highly scalable and flexible database-centric applications. Without these elements, we'll only get more high-minded marketing hype without the product features to back it up.