Database Integration Better Late than Never

Developers can expect another quantum leap in data-manipulation power with Microsoft's integration of its SQL Server engine with its CLR environment.

Microsoft Corp.s planned integration of database-oriented programming tools pays belated homage, one might say, to computer scientist Niklaus Wirths famous assertion that "Algorithms plus data structures equal programs."

Wirths 1975 book by that title immediately followed his invention of the Pascal programming language, which raised the bar for data-structure support in programmers tool sets. Developers can look forward to another quantum jump in data manipulation power as Microsoft Corp. unifies the mechanics and the semantics of its SQL Server database engine with its CLR (Common Language Runtime) environment.

The resulting union will coordinate resource use—with likely significant improvements in efficiency—and could evolve during the next several years to offer developers a powerful model for data manipulation.

/zimages/6/28571.gifClick here to read about Microsofts plans to integrate Visual Studio 2005 with SQL Server 2005.

Programmers may find more freedom to choose between putting logic close to data, while retaining their familiar high-level languages, or keeping their logic located on middle tiers while retaining robust database protections.

Developers will also have more freedom to make the database itself a locus of events. "Its a service-oriented database architecture," said David Campbell, Microsofts general manager for SQL Server, discussing this massive integration effort with eWEEK Labs.

Campbell acknowledged, and promised to address, programmers perennial concern that higher-level language features will come at the expense of performance. That tension dates at least to 1982, when Ed Posts classic tongue-in-cheek essay "Real Programmers Dont Use Pascal" made the facetious assertion that "the only useful data structure is the Array. Strings, Lists, Structures, Sets—these are all special cases of arrays and can be treated that way just as easily without messing up your programming language with all sorts of complications."

In the absence of those "complications," what tended to get messed up—as Post knew perfectly well and as many others have since observed—was programmers understanding of one anothers (and often even their own) intentions. Theyve been forced to devise their own brittle and error-prone frameworks of containers, iterators, cursors and the like.

Lacking strong data type definitions and disciplines as built-in elements of their application programming kits, programmers have either confronted—or perhaps more often overlooked—the difficulties of dealing with null values, defining equality between multivalued entities and ensuring correctness in data structure formation and data use.

With database access as the dominant task of the vast majority of enterprise applications, its none too soon for developers to be offered something better than awkward mixed-language mongrelizations of procedural languages and embedded SQL code.

One can debate the question of how many years represent a generation of software development, but Wirths insights have arguably had about two generations to make themselves part of development DNA. Enterprise teams can hope to benefit from that breeding in forthcoming Microsoft tools.

Technology Editor Peter Coffee can be reached at

/zimages/6/28571.gifCheck out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.