Select Content Type
What kind of article do you want to create?
Close Window
Article
Schedule
ArticleID
54656 - Click to preview
Canonical URL
https://www.dbta.com/Columns/SQL-Server-Drill-Down/The-Future-of-Coding-for-SQL-Server-Part-2-54656.aspx
Title
StandOut Url
Author(s)
Kevin Kline
Images
Related Articles
Summary
The Future of Coding for SQL Server, Part 2
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Video
<p>In my last column (published in the <a href="https://www.dbta.com/e-edition/Feb09/8-column_kline.html">February e-edition</a> 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.</p><p>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.</p><p> 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 <em>everything</em> 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.</p><p>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.</p><p>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.</p><p>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.</p>
Newsletter Name
Issue Name
Article Type
Article SubType
DBTA E-Edition
March 2009
Columns
SQL Server Drill Down
Please Choose
5 Minute Briefing : Blockchain
5 Minute Briefing: Cloud
5MB: Data Center
5MB: Information Management
5MB: MultiValue
5MB: Oracle
5MB: SAP
Big Data Quarterly Issue
Cloud Strategies
DBTA E-Edition
ExaBriefing
Headlines from AIOUG
IBM LinuxLine
Infrastructure Wisdom
IOUG Storage Systems
Linux Executive Report from IBM
Magazine Issue
Oracle Enterprise Manager
Unisphere Five Minute Briefing
Columns
Editorial
A Wider View
Applications Insight
Big Data Notes
Database Elaborations
DBA Corner
Defining Data
Emerging Technologies
From 30,000 Feet
MongoDB Matters
My View
MySQL Musings
New Directions
Next-Gen Data Management
Notes on NoSQL
Oracle Data Strategies
Oracle Observations
Quest IOUG Database & Technology Insights
SQL Server Drill Down
The Enterprise Environment
The Open DBA
The Philosophy of PL/SQL
Trends and Observations
Categories
Topics
Artificial Intelligence
Big Data
Blockchain
Business Intelligence and Analytics
Cloud Computing
Data Center Management
Data Integration
Data Modeling
Data Quality
Data Warehousing
Database Management
Database Security
Hadoop
Internet of Things
Master Data Management
MultiValue Database Technology
NoSQL Central
Virtualization
×
Authors
×
Search Articles
×
Image Helper
Upload an Image
Name
File
Browse…
Image Resize (width):
90
120
135
250
No resize
Preview (Click image to select)
Select the Image
ID
Image Name