PS: We'll be sorting different trace events in the CLR, whether it's garbage collection or invoking functions or other activity. I can't give exact details because we're still working them out, but our goal is to expand Profiler's reach because we understand the importance of making sure DBAs have the information they need to manage performance and other aspects of the database.
BM: Another Yukon question: Will Microsoft expand our ability to construct XML queries, and will SQL Server's query processor and storage engine be able to store and manipulate XML natively so that we can index and search XML?
PS: Microsoft saw the importance of XML early on and put a lot of work into designing deeper XML support within the SQL Server engine, both in the query processor and the storage engine. In Yukon, we'll be implementing some sort of XML data type, along with a deep knowledge of that data type in terms of indexing or querying using X-Query or Data Manipulation Language (DML). We're taking a lot of what we learned in implementing XML on the middle tier and pushing those capabilities that make sense down into the database engine. We're not building on the top of or on the side of—we're building this integrated functionality deep into the engine. Because of this integrated approach, you'll be able to load XML into SQL Server, back up the XML, and query and manipulate it. And it will be lined up correctly with the metadata and DDL. Essentially, we're making an engine that lets you do relational access and XML access.
We're also including native support for HTTP and Simple Object Access Protocol (SOAP) in the product, which lets us directly expose XML Web services. So, you'll be able to talk HTTP as an alternative to Tabular Data Stream (TDS). We think this will let us play in the Web services space directly as a better component server.
BM: Let's talk about T-SQL for a moment. T-SQL is a very logical language, and programmers should be able to concentrate on queries being logically correct without having to worry about performance. The SQL Server team has done a lot of work to make the query optimizer more sophisticated with every release. However, different queries that perform the same task and generate the same result set still sometimes run through different execution plans and perform differently—sometimes in orders of magnitude. How far are we from having an optimizer that can always tell that two different queries that perform the same task are actually the same, then produce the same execution plan for both?
PS: I believe the optimizer gets smarter with every release, and we're getting a lot smarter at how to test it by using tools against generated and real workloads. But when you're trying to generate the correct query, it's hard to come up with just one right answer. Optimizing queries is sometimes more of an art than a science. As you noted, we built a new optimizer in SQL Server 7.0, thinking a lot about stability of plans and so on. But invariably, when you release a new optimizer version, 90 percent of the queries get faster, a few remain the same, and a few get worse. We use automatic SQL generators that help us test, compare, and make sure that the plans SQL Server generates are the proper plans. We also have workloads and queries from real customers, and we study the query plans being generated for those. We think we have the right framework for continually making progress, and we think our automated tools will help us work on those 2-3 percent of queries that get slower after a new release.
BM: Depending on who you talk to, .NET might mean the CLR, Web services, Visual Basic .NET, or a number of other technologies and directions. What does—and will—. NET mean to the SQL Server community?
PS: Here's how I think about .NET. A major portion of .NET is about storage—a storage engine for distributed programs. So a lot of features that we have in SQL Server, such as XML support, are really setting the product up to be something beyond the traditional database that we've built over the past 20 years. For example, the new Notification Services for SQL Server 2000, which lets you develop and deploy applications that generate and send personalized notifications, goes beyond the functionality of a traditional database system. We're seeing a big market for Notification Services from people who want to be notified when, say, their stock price changes or their plane is late. We put a lot of value on the dynamic nature of things, not just static behavior. So, for example, we're doing work in query notification—working with ASP.NET so that when things happen in the database, we can notify different products up the stack to take appropriate action.
Every indicator we look at says we'll be building more and more distributed applications in the future. And so much of what we're developing for Yukon and beyond—in terms of programmability, notification, XML, and so on—makes us the right platform for building these distributed apps. We're looking at SQL Server as a sort of subsystem—the structure under the covers that lets you build distributed applications. The relationship between SQL Server and .NET is really about storing information in multiple ways, from supporting large databases, to facilitating the dynamic nature of databases, to supporting XML and HTTP access.
BM: You touched on the idea of SQL Server being a storage engine for things above and beyond what we typically think of as belonging to a database. What kind of work is Microsoft doing around that concept?
PS: You're right, the technology we're building is becoming more and more important for Microsoft. First, we built a great database. That success opened a lot of eyes at Microsoft and opened a lot of opportunities to use this technology with a lot of different products. Probably 90 percent of my people are core database people—that's what we live and breathe for and think about. That being said, we've built a valuable technology, so why should we continue to build one-off technologies that try to do similar things for different products?
If we hadn't made the early push on SQL Server's serviceability, ease-of-use, self-monitoring tools, and other manageability functions, it would be difficult to pick up the traditional database and steer it toward these other uses. But because we did focus on serviceability, we're finding that it's not that complex to take the technology, talk to different customers both internally and externally, and understand what they need to do and how much we need to change the product. Again, Notification Services is a good example. We didn't have to change SQL Server much at all because it already had the functionality to solve this kind of messaging problem. Yes, it's stretching us a bit to have a good number of people thinking about problems in different dimensions and different domains. But we find it fitting very naturally with what we've already built. And XML is helping because we already have a lot of data structures and access patterns lined up with the way the company's thinking about using this technology in the future.
End of Article
Prev. page
1
2
[3]
next page -->
