Multilingual SQL Server

One of SQL Server's weak points when critics compare it with DB2 and Oracle is its lack of programmability. Longtime SQL Server users might find this criticism strange. From the developer standpoint, SQL Server seems to be the most programmable database around. OLE DB providers and ODBC drivers let you easily connect to the database from virtually any language and from a multitude of clients, including non-Windows ones. Even from the DBA perspective, SQL Server appears eminently programmable. You can manage virtually every aspect of the database, from creation to tuning, through T-SQL. And whatever you can't do in T-SQL, you can accomplish by using SQL Distributed Management Objects (SQL-DMO).

Sounds simple, right? Therein lies the problem. While certainly a capable scripting language, T-SQL lacks many features—including object orientation, inheritance, and polymorphism—found in most modern programming languages. Thus, you can't use T-SQL to program every kind of solution.

That's the story today. But the Microsoft SQL Server team is on a mission to make SQL Server the world's number-one database. The team has already boosted the database's reliability, scalability, and functionality in SQL Server 7.0 and 2000. And the Microsoft developers have listened closely to the programmability criticisms leveled at SQL Server and are working to address those concerns in the next release of SQL Server, code-named Yukon. With Yukon's integrated Windows .NET Common Language Runtime (CLR) support, the SQL Server team is writing a new chapter in SQL Server's programmability story. Integrated support for the CLR will let DBAs and developers use any of the CLR languages—including Visual Basic.NET (VB.NET), C#, and Visual C++ (VC++)—to create database components that you can currently build only by using T-SQL. Although T-SQL will continue to be a high-profile database language, support for other languages will lay to rest any lingering SQL Server programmability concerns.

Increasing SQL Server programmability is a good thing, but it raises an interesting problem. Although more modern languages, such as VB.NET and C#, have features that make developing complex programs easier, these languages aren't based on SQL and don't have the same efficient, set-at-a-time orientation. T-SQL, in contrast, is a version of standard SQL, with a smattering of programming constructs to provide logic and flow control. This SQL foundation gives T-SQL a natural set-at-a-time orientation that, when used correctly, makes T-SQL solutions natural for DBAs to develop and efficient for relational database access.

How effectively Microsoft will bridge this language-performance gap remains to be seen. But throwing more capable and more complex—but less SQL-oriented—.NET languages into the mix increases the likelihood of performance potholes. To compete as a world-class enterprise database, SQL Server must support other languages. But to ensure that database applications written in these languages work as efficiently as possible, DBAs must be conversant in these languages. Parlez-vous C#?