What's new in SQL Server Yukon - Part 2
Tim Anderson talks to Euan Garden, Microsoft's Product Unit Manager for SQL Server Tools
Euan Garden
Tim: MSDE, the desktop engine is useful. Is that continuing?
Euan: Absolutely. We don't have the plans for MSDE as firmed up as we do for the rest of the box. Over the last 18 months we've realised that MSDE is more successful than we had hoped. We're taking a step back, which we didn't do with the initial release or with MSDE 2000. Rather than saying "what features of SQL Server are we putting in MSDE," we're taking a look at the apps the customers are building, and looking at the issues. We started an MSDE newsgroup. It's now number two or three of all SQL Server newsgroups by number of postings. So we spend a lot of time there.
The Web Matrix project put MSDE in the hands of a lot of people. We're looking at feedback from those ASP.Net developers. So we're looking at doing different things with MSDE, none of which are defined at this point. But for sure there will be an MSDE. There won't be an MSDE in beta 1, which is a private beta coming in August 2003, but there will be for the public beta 2 next year.
And we're also making some other changes focusing on developers. We recently dropped the price of the Developer Edition from the $500 to the $49 (£39.00 in the UK). One of the great things with the Developer Edition is that it gives you the redist rights to MSDE. We're very clear. You have Developer Edition, you have redist rights to MSDE. The other thing is, we don't want developers developing with MSDE. It's a great deployment engine, but it's a little more challenging to work with as a development tool, so we wanted to make sure that all developers have access to SQL Server Developer edition to make it easier to design and build their apps. One aspect of that is the price cut, the other one is the licensing deal with Borland which is allowing them to put Developer Edition in CSharpBuilder. They also have MSDE redist rights in their product.
Tim: There are hints about both Exchange Server and the Windows file system involving Yukon at some point in the future. Is that influencing Yukon itself?
Euan: In some ways yes, in some ways no. There are lots of Microsoft products that build on SQL Server today. MOM, SMS, Appcentre, Commerce Server, Content Management Server, BizTalk Server, the list goes on. Those essentially are ISV's to us, just like SAP or PeopleSoft would be. They submit feature requests. One of the big hurdles we've crossed is that with our support for XML, we can support semi-structured data much better than we could in SQL 2000. That's a big deal for products like Exchange. We certainly worked closely with the Exchange team to make sure we could meet their requirements. The Exchange team is committed in a future version, not yet decided, to build on top of Yukon as a store, or the version after Yukon, depending on timing.
What Windows is going to do is leverage some of the relational technologies which exist in the database to enhance the file system. So Yukon is not being put into the operating system. But they are going to leverage some of the code that we have. That's all we're saying about the file system at this point. At PDC in Los Angeles later this year, we will talk about the new Windows File System, Longhorn, and all the new technologies.
Tim: It concerns me that embedding SQL Server too deeply might cause database applications to slow down because of other services accessing the engine.
Euan: From the file system perspective it's not the SQL Server engine that you're going to be talking to, so that's a good thing. There's also the support for multi-instance that we did in SQL 2000, which allows application isolation. In SQL 2000 we support 16. In Yukon the goal is to support 50.
There could be a scenario, and this is not decided yet, where you could run Commerce, MOM, Content, Biztalk, all on the same SQL Server, but each one would have its own instance. Therefore you have isolation for security reasons, for performance, and for predictability reasons as well. That's one of the driving factors behind doing that multi-instance capability.
Tim: Does the new XML capability make it easier to persist objects as XML?
Euan: Absolutely. There are two technologies coming in Yukon which make that much easier. The first is the native XML type. So rather than XML being shredded as it is today, you can declare a column type of XML. If you use XML-based serialization in .Net objects you can literally stream that XML into the column. And you can constrain that column using an xsd-based schema. So we have validation in there as well. We think that's going to be a big win for developers.
The second area is that we have a technology called Objectspaces, which actually was in one of the earlier betas of the Framework but was removed. We will re-ship with the Whidbey version of Visual Studio and SQL Server. It's an object-relational mapping layer. For example, you could have Customers and Orders, and Customers could be mapped to 20 or 30 tables. You don't know and you don't have to know. At some point you have to design your app and say, "here's an object and here's how it maps into the relational data", but the actual meat and potatoes of worrying about how those two talk to each other is handled for you by the Objectspaces API. So rather than building a true object-oriented store, we have XML which supports a degree of object support using serialization, and Objectspaces which support object-based interaction to a relational database. I think we stand a strong chance of satisfying developer need with those.
Tim: What benefits do I get from the XML column type?
Euan: The first thing is that we can index the XML natively. Today when we store XML we actually shred it for you, or you can store it in a varchar. You can't do much interesting in terms of indexing a varchar, particularly if it's a large document. By storing it we can index it, so you index it by the different components inside the document. That's very powerful. We can very easily do inserts and updates into individual nodes and elements without loading the entire thing into the DOM. We're using SAX-based technology to run through the entire document, and find the place where you want to insert or change even one character in the document. We can be much more efficient and therefore scaleable.
Tim: So let's say I had a Person document which has a LastName element. Can I index that LastName element and then search for LastName = "xyz"?
Euan: You can't index elements but we will index on the document itself, so it will be much more efficient. If you're doing a lookup by LastName, it will be orders of magnitude faster than it is today. We're still closing down some of the XML-based indexing. So that's one of the places where we're looking for feedback.
Supporting XQuery now allows us a much richer query language for insert, update and select operations. And we've also implemented this in a way that allows us to mix and match relational and XML data. What we've found is that people generally don't store only XML. For example, in a Customer table they might have relational columns for lastname, zipcode and things like that, but because there could be multiple mobile phone numbers, maybe that column is actually in XML. By using XQuery technologies we can pull that data out, including XML data, and present it to you as a relational result set. Or we can pull out the data as an XML document, including what is really relational data, and you can interact with it as XML. document. It comes back to choice.
JDBC, Report Server and more - click here for the final part of this interview
Go back to part one of What's new in Sql Server Yukon
Copyright Tim Anderson 25th July 2003. All rights reserved.
Sign up to be notified of future articles
Professional SQL Server 2000 Programming by Robert Viera
Details here for US
Details here for UK
SQL Server books
Bestselling SQL Server books