Next Generation SQL Server - Yukon
I know that this is one topic that has raised interest
in minds of many database designers. The next generation of SQL Server is
full of promises. With the release of Yukon we will be able to
do amazing things. What I would try to do here is to enlist some
of the public information published on the internet. There are tons of
links that come up if you were to search for "Yukon" on any search engine.
We will try to highlight some interesting features available from the net. You
can also visit the
to get a list of some of the links.
As per Campbell (Microsoft product unit manager
for the SQL Server Engine), Microsoft is also working on making its XML
features "deeper," he said. The company released an XML update this fall,
focusing on making the common language runtime and the application frameworks
of .NET run inside the database itself. That was a huge shift from the past,
Mangione said. All further work on XML will continue to be done in-house—it
would be too difficult for Microsoft to integrate with another vendor's native
XML database, he said. XML databases alone are a successful niche product.
But Web services are a foundational technology in the
new product. "Web services plumb directly in Yukon," Campbell said. "Yukon can
directly host Web services and will generate standard WSDL [Web Services
Description Language] for binding in clients."
"We're making a ton of investments in developer
productivity," Campbell said, noting that developers can write "stored
procedures in any CLR language." Another new feature of Yukon is its
integration with the Common Language Runtime (CLR), which supports development
in more than 25 languages.
According to Tom Rizoo(Microsoft Group Product
Manager), We upped the level of XML support in Yukon through a number of
things. In 2000 we had XML support but … it was shredding. [Shredding is the
parsing of XML tag components into corresponding relational table
columns.] In Yukon the key thing is we have an XML type. Like you have
STRING and NUMBERS and all that inside the database, now you can declare [with
the native data type] XML. Although we had XML support in 2000, and many
leveraged it and were happy with it, now we have native support.
Our goal is that Yukon will at least meet the same
performance as SQL Server 2000, but we're hoping it exceeds it. That's in all
aspects, not only in terms of what SQL Server 2000 has, but some new
capabilities. For example, writing code in .Net should be the same as writing
code in the T-SQL environment.
.Net code today doesn't run within SQL Server. It
runs separate, outside the database. In Yukon we've put it into the database.
Our plan is that T-SQL and .Net technologies will run at the same speed. The
reason we're putting .Net inside the database is now customers can write SQL
Server business logic inside the database using any .Net language. For example,
you can use C# or Visual Basic. We're also talking with Fujitsu, who builds
Building on SQL Server 7.0 and SQL Server 2000, SQL
Server "Yukon" will deliver an end-to-end business intelligence platform with
integrated analytics including online analytical processing (OLAP); data
mining; extract, transformation, and load (ETL) tools; data warehousing; and
reporting functionality. This comprehensive, integrated approach will enable
organizations to seamlessly build and deploy robust business intelligence
applications while controlling costs.
Developers will be able to utilize one development
tool for Transact-SQL, XML, and Multidimensional Expression (MDX). Integration
with the Visual Studio® development environment will provide more efficient
development and debugging of line of business and business intelligence
applications. SQL Server “Yukon” will also include robust enhancements to the
Enhanced high availability technologies, additional
backup and restore capabilities, replication enhancements, and "secure by
default" settings will help enterprises to provide users with secure,
consistent access to enterprise applications.
According to Campbell (Microsoft product unit manager
for the SQL Server Engine), Yukon characterized as a "fourth generation"
database that is optimized to provide "autonomous computing." Microsoft
executives have used the autonomous computing label to describe interactions
between computers that don't trust each other.
Campbell highlighted Yukon's Common Language Runtime
(CLR) integration, built-in Web services support, new messaging features,
support for new datatypes and general scalability and availability advances.
Yukon won't be an XML database, but will rather
integrate support for XML data types into the relational SQL Server database.
Yukon will be tightly integrated with Microsoft's
Visual Studio .Net development suite, Campbell said. That way, database
programmers will have access to Visual Studio's authoring, debugging, profiling
and IntelliSense capabilities.
You will no longer be required to use
Transact-SQL to write SQL Server stored procedures, triggers, and user-defined
functions. You'll be able to create these objects using any of the .NET
languages -- VB.NET, C#, C++, or even COBOL.NET -- and compile them into .NET
One important benefit of relying on the
.NET Common Language Runtime is that it can verify that all code hosted by SQL
Server won't cause any memory usage errors that would bring down the server. In
addition, SQL Server will benefit from the CLR's robust support for versioning
Data access in Yukon will be based on a new set of
managed interfaces in ADO.NET. This new set of ADO.NET classes will be grouped
within a namespace that is currently being called System.Data.SqlServer, and
these classes will interact directly with SQL Server's internal query
SQL Server will also leverage the Common Language
Runtime's code access security model. By default, code doesn't have any
permissions to create a graphical user interface, create threads, access the
file system, or call unmanaged code. The only permissions implemented are those
granted for in-process SQL Server data access.
Altering assemblies will not be allowed to invalidate
persistent data or indexes. For example, suppose you have an indexed, computed
column that relies on a .NET function to perform the computation. Changing or
dropping this function would invalidate any data stored in that index.
Dependencies are tracked, and you can't drop an assembly if dependencies exist.
In Yukon, you can encapsulate your middle-tier logic
within server-side components and still have all the advantages of running as
compiled machine code, not interpreted Transact-SQL. This won't make much of a
difference for code that's primarily performing data access; the goal for
Microsoft is that CLR data access code will execute as fast as the equivalent
code written in Transact-SQL.
Relying on .NET code won't hamper the
scalability of your SQL Server database operations. Yukon's ability to handle a
given number of concurrent users with a given set of hardware resources will be
as good as (or better) than that of SQL Server 2000.
If you already have a significant investment in
existing Transact-SQL code, there is no need to worry. Transact-SQL will
continue to be fully supported. Transact-SQL itself will be enhanced to support
new functionality not currently available.
A new developer tool called the SQL Server
Workbench will support deployment of assemblies to multiple servers and will
contain a powerful subset of Visual Studio.NET capabilities for code
management. It's too early to tell what the SQL Server Workbench will actually
look like, but it will most likely resemble the user interface currently
available in Visual Studio.NET.
According to Euan Garden (Microsoft's Product Unit
Manager for SQL Server Tools), SQL CLR (Common Language Runtime) is
significant, which is the ability to host CLR-based languages inside SQL
Server. It gives developers language choice and architectural choice. We've
tried to make it as seamless as possible to write code for the middle tier,
move it into the database, and move it back out again.
The investments we're making in business intelligence
are huge. Reporting services are coming, and there'll be a version for SQL 2000
as well as a version for Yukon.
I think the XML-based technologies are huge as well.
The new XML data type, the new XQuery-based technologies. And then there's the
bread and butter, the database engineering, more scalability, more reliability,
partitioning, faster backups, more reliable backups.
The CLR programming environment allows us to do
stored procedures, functions, triggers, user defined data types, and user
defined aggregates. It's not just stored procedures.
When asked about the CLR languages support, he said
we're committed to VB.Net, C# and managed C++ in the initial release.
According to Eric Brown (Poduct Manager for SQL
Server), The integration of SQL Server "Yukon" with the .NET Framework
represents the delivery of a more symmetrical programming model between the
middle and database tiers. Writing database logic in either Transact SQL
(T-SQL) or any .NET-compliant language means greater productivity for
XML integration is as important as the .NET Framework
integration. SQL Server "Yukon" will ship with a full-fledged XML data type
that will support XSD for schema validation.
SQL Server "Yukon" has just entered Beta 1. We will
do more betas as we get feedback from customers. Our current goal is to have a
public beta in the first half of 2004.
Note: All the views and contents are from the various
sites outlined above. We have consolidated some information from the same.