Ships from: Wilmington, NC
Usually ships in 1-2 business days
Ships from: Evans, GA
Usually ships in 1-2 business days
Ships from: Portland, OR
Usually ships in 1-2 business days
Ships from: San Marino, CA
Usually ships in 1-2 business days
Anonymous
Posted Thu Sep 23 00:00:00 EDT 2004
Databases are at the core of most software projects these days and there is a fair amount of competition between software vendors for a bigger share of a lucrative market. However, it would be fair to say that only DBAs really know what their database servers are capable of and maybe only half of them really everything that their software can do. One of the biggest arguments for this First Look At SQL Server 2005 book then is as a prospectus for all the developer-related features and functional nooks and crannies that the next incarnation of SQL Server (codename 'Yukon') will contain. Split over seventeen chapters and two appendices, this very thorough book covers the ins and outs of four main topics - SQL Server as a CLR host, XML, enhancements to the existing features of SQL Server 2000 and notification services - that should be of interest to developers looking forward to a world of Whidbey and Yukon. Topics such as security and XQuery aren't exhaustive - they'd each take up a book on their own - but all the main points within the context of this book are covered. Indeed, with the exception of Chapter 14, which covers a feature since removed from SQL Server 2005 but is well written anyway, each chapter is clean, concise and packed with useful information. The author team of three have produced a book that at times goes as deep into detail as Don Box's Essential .NET does while treating 'lighter' topics such as Microsoft's new enhancements to T-SQL, in no less detail but in an easier to read style. The main focus of this book are the new opportunities for developers to utilize Yukon but administrators can also take a lot away from this book having been made aware of areas that developers may focus on. In all, this is an excellent preview book on developing with SQL Server 2005 in mind and should be kept around until the revised version comes out for the actual release of this new database.
Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.Anonymous
Posted Mon Aug 09 00:00:00 EDT 2004
Microsoft continues to integrate its SQL Server deeper into its .NET framework. One result is this book, with a heads-up on new features with a nominal release date of 2005. YOu can see a lot of changes. Most significant, perhaps, is that the .NET CLR engine is now embedded into the SQL Server engine. So that stored procedures can now be written, and in several .NET languages, at that. Stored procedures are a key optimisation technique of sophisticated databases, so it is very good to see it here. Hmm, I wonder. This book scrupulously avoids mentioning any rival databases. But at the low end, SQL Server has to ward off the free MySQL. The latter lacks stored procedures [for now]. So this lets Microsoft put some distance between them. Plus, above SQL Server in functionality sits Oracle and dB2. So stored procedures help close the gap here. Another interesting note about the book is the sheer space devoted to integrating in XML. There is now a native XML data type in SQL Server. All relational databases are having to move towards handling XML. This also makes it harder for pure object oriented databases, like Versant, to make inroads when major databases like SQL Server handle XML.
Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
More About This Textbook
Overview
Be the first to master SQL Server 2005's breakthrough database development capabilities
Few technologies have been as eagerly anticipated as Microsoft SQL Server 2005 ("Yukon"). Now, three SQL Server insiders deliver the definitive hands-on preview—accurate, comprehensive, and packed with examples.
A First Look at SQL Server 2005 for Developers starts where Microsoft's white papers and Web articles leave off, showing working developers how to take full advantage of Yukon's key innovations. It draws on exceptional cooperation from Microsoft's Yukon developers and the authors' hands-on access to Yukon since its earliest alpha releases.
You'll find practical explanations of Yukon's new data model, built-in .NET hosting, improved programmability, SQL-99 compliance, and much more. Virtually every key concept is illuminated via sample code tested with Microsoft's public beta.
Key coverage includes:
Already committed to SQL Server 2005? Simply evaluating it? Looking to set yourself apart from other SQL Server developers? Whatever your goal, start right here—today.
Editorial Reviews
From Barnes & Noble
The Barnes & Noble ReviewMore new features have been added to SQL Server 2005 (a.k.a. Yukon) than to any previous version. (No wonder it’s taken so long to ship!) These features can help developers accomplish remarkable things. Now the creators of Microsoft’s five-day Yukon workshops have written a developer’s preview of exceptional technical depth.
With Microsoft’s .NET CLR engine deeply embedded in SQL Server 2005, stored procedures and triggers can be written in most .NET languages. That’s huge, and this book’s DevelopMentor authors help you take full advantage. You’ll find detailed coverage of improvements to security, plus a full section on Yukon’s outstanding XML support (native XML data type functionality, XQuery support, and much more). The authors illuminate SQL Server Service Broker, Microsoft’s challenging new framework for large-scale, line-of-business applications. If you even suspect you’ll be creating SQL Server 2005 applications, you should own this book. Bill Camarda
Bill Camarda is a consultant, writer, and web/multimedia content developer. His 15 books include Special Edition Using Word 2003 and Upgrading & Fixing Networks for Dummies, Second Edition.
Product Details
Related Subjects
Meet the Author
Bob Beauchemin is a database-centric application practitioner and architect, DBA, instructor, course author, and writer. He's Director of Developer Skills at SQLskills (www.sqskills.com), and teaches his SQL Server 2005 courses around the world. Bob has written extensively on SQL Server and other databases, database security, ADO.NET, and OLE DB.
Niels Berglund, Microsoft Valued Professional for OLE DB and ADO, teaches .NET and Microsoft data access for DevelopMentor. He has consulted widely on the development of distributed financial applications built with SQL Server.
Dan Sullivan runs his own consulting company, does training for Pluralsight (www.pluralsight.com), and has worked with SQL Server since it was first distributed by Microsoft and ran on OS/2. Dan has spoken and written widely on SQL Server.
Read an Excerpt
After my last book, Essential ADO.NET, was handed in to the publisher ten days before .NET 1.0 shipped, I swore I'd never write another. To keep up with a technology while it was developing and the product features were being refined on an almost daily basis was too big an energy sink. Then, less than a year later, I caught wind of a new version of SQL Server, code-named Yukon. As with each version of SQL Server before it,since Microsoft's original 4.21 offering, there were lots of features for DBAs—high-availability features, tuning features, scalability features, andso on. A new, fast-growing field called business intelligence was being developed,and SQL Server was on the cusp of this. The features in this business intelligence area of Yukon were truly astounding. But the biggest changes that caught my eye were those in the developer area. I was hooked.
Transact-SQL has served us developers well all these years and continues to work quite well, thank you. This book lists the enhancements to this procedural dialect of SQL, and that chapter ended up to be much longer (because of the number of enhancements) than I originally thought. In the last few years, I'd been spending a lot of time in the
In addition, beginning with the object-oriented graphical user interface on the NeXT computer, I'd spent a lot of the last ten years using object-oriented techniques. And Yukon promised to integrate the .NET runtime into the database engine itself. Not that SQL Server internals were to be written in .NET, but that .NET would be directly accessible as a language for stored procedures and user-defined functions. I could use object-oriented programming techniques with my database programming as well. This might be a big assist to the procedural programming in T-SQL I was already doing, in those cases where I needed it. I'd read about using object-oriented languages in the ANSI SQL specifications. Finally, there was the rumor that .NET classes might be available in SQL Server as types that the server knew about. I'd read the ANSI spec for that too. I just had to see this product.
So we had been working on writing this book since late 2002 when I met with Eric Brown in Redmond, Washington, and we got the OK and the software. Since 2002 we'd badgered the SQL Server and Webdata teams with copious questions about not only how the software worked but why it was designed that way. They were very understanding about our persistence,but sometimes I felt that I was being a bit of a pest. When we started to teach the class in earnest, we tried to pay them back with information about how software vendors and others thought the features would be useful. At that time, Niels and I were writing, and Dan was reviewing and making suggestions; however, Dan got hooked too. We almost published in the beta 1 time frame, but held back. There were too many major enhancements to the way things actually worked, and we'd written about how things worked too early. Readers would think things worked the old way instead of the improved way. And there were more enhancements coming in beta 2. We held off writing and went for another revision. We were permitted, however, to write and teach a class to early adopters, based on the current state of our work and of the product. I think we've taught about 400 to 500 students as of this writing. The product evolved. More revisions. I'd told Mary that I was "almost done" so many times that she shook her head and laughed when I mentioned I might really be done again five minutes ago. It's certainly possible that some of the features or the implementation of them could change between now and when SQL Server 2005 ships. We'll try to keep you up to date with all the changes, update the book's code examples, and post some additional samples on the book's Web site. Look for pointers to the code and updates at the following locations:
Yukon has all the stuff that I'd read about and more. At a SQL*PASS conference, I ran into Roger Wolter, a friend from the SQL Server team. We'd originally met when I was speaking at a Web Services conference on SQL
So far I've mentioned Service Broker, Transact-SQL enhancements, security, .NET-based procedures, functions and user-defined types, built-in
Finally, there are those developers who would rather not know that the database exists at all. They deal in objects and would just like to call "Load" and "Save" on their object model and have it taken care of. They're more interested in their business or application domain than in how to create a distributed partitioned view to spread the Customer table over multiple SQL Server instances. They see only Customer instances and collections. For these folks, ObjectSpaces and Microsoft Business Framework are what float their boat in this release. In addition to being able to persist their instances, they want "Load" and "Save" to take nanoseconds. ObjectSpaces was designed with optimization in mind.
In conclusion, I think there's quite a bit in Yukon for just about every developer, DBA, application designer, business analyst, and data miner. I've read in some trade publications that the new features just aren't that interesting; they're more like a recitation of glitzy acronyms than substance. This may be the initial perception, but let's rewind to mid-1981. I'm working for an insurance company in Seattle, and we're planning to convert our indexed file data, which we'd just converted from ISAM (indexed sequential access method) to VSAM (virtual storage access method), to a better, more robust database engine. The one we had in mind was IMS (IBM's Information Management System product). The salesperson, however, wants us to look at some new-fangled database they call SQL/DS (which eventually became DB2). After designing some tables and playing around with some queries, we asked some tough questions like "Why does it matter that a database engine is built on a mathematical theory?" and "Why would you want to learn a foreign query language called SQL rather than using nice, fast assembly language or COBOL programs?" and "Why did you just decompose our 2 nice, understandable records into 30 little tables just to join them back together again?" and "Why does it go so slow?" It was the beginning of the relational era. Relational engines weren't all that optimized yet, and smart programmers with fast disks could beat the engine every time. In 1981 we sent the product back, and I didn't learn SQL until 1987. By then I was a bit behind on the learning curve, but relational engines were a heck of a lot faster, and programmers wrote a little SQL and much less procedural code. And they got much more work done. So I smile when I see folks shake their head about the
Bob Beauchemin Portland, Oregon, March 2004
Table of Contents
Preface
After my last book, Essential ADO.NET, was handed in to the publisher ten days before .NET 1.0 shipped, I swore I'd never write another. To keep up with a technology while it was developing and the product features were being refined on an almost daily basis was too big an energy sink. Then, less than a year later, I caught wind of a new version of SQL Server, code-named Yukon. As with each version of SQL Server before it,since Microsoft's original 4.21 offering, there were lots of features for DBAs—high-availability features, tuning features, scalability features, andso on. A new, fast-growing field called business intelligence was being developed,and SQL Server was on the cusp of this. The features in this business intelligence area of Yukon were truly astounding. But the biggest changes that caught my eye were those in the developer area. I was hooked.
Transact-SQL has served us developers well all these years and continues to work quite well, thank you. This book lists the enhancements to this procedural dialect of SQL, and that chapter ended up to be much longer (because of the number of enhancements) than I originally thought. In the last few years, I'd been spending a lot of time in the XML space and done a lot of thinking about the differences and similarities between the XML and relational models. I liked the formal W3C standardization process for XML, slow as it seems at times. I started to investigate the ANSI SQL standards in earnest, though I'd read them before, and realized that SQL has a rich and deep foundation, starting with SQL-86 and up to the last mainstream standard, SQL-92, and past that to SQL:1999. But in 2002 there werespecifications in progress to define how XML would be integrated into a relational database. There was a synergy with the XML work I'd been doing lately. I heard there would be XML functionality in Yukon, including an XML data type, XML schema validation, and an implementation of the emerging standard query language for XML, XQuery.
In addition, beginning with the object-oriented graphical user interface on the NeXT computer, I'd spent a lot of the last ten years using object-oriented techniques. And Yukon promised to integrate the .NET runtime into the database engine itself. Not that SQL Server internals were to be written in .NET, but that .NET would be directly accessible as a language for stored procedures and user-defined functions. I could use object-oriented programming techniques with my database programming as well. This might be a big assist to the procedural programming in T-SQL I was already doing, in those cases where I needed it. I'd read about using object-oriented languages in the ANSI SQL specifications. Finally, there was the rumor that .NET classes might be available in SQL Server as types that the server knew about. I'd read the ANSI spec for that too. I just had to see this product.
So we had been working on writing this book since late 2002 when I met with Eric Brown in Redmond, Washington, and we got the OK and the software. Since 2002 we'd badgered the SQL Server and Webdata teams with copious questions about not only how the software worked but why it was designed that way. They were very understanding about our persistence,but sometimes I felt that I was being a bit of a pest. When we started to teach the class in earnest, we tried to pay them back with information about how software vendors and others thought the features would be useful. At that time, Niels and I were writing, and Dan was reviewing and making suggestions; however, Dan got hooked too. We almost published in the beta 1 time frame, but held back. There were too many major enhancements to the way things actually worked, and we'd written about how things worked too early. Readers would think things worked the old way instead of the improved way. And there were more enhancements coming in beta 2. We held off writing and went for another revision. We were permitted, however, to write and teach a class to early adopters, based on the current state of our work and of the product. I think we've taught about 400 to 500 students as of this writing. The product evolved. More revisions. I'd told Mary that I was "almost done" so many times that she shook her head and laughed when I mentioned I might really be done again five minutes ago. It's certainly possible that some of the features or the implementation of them could change between now and when SQL Server 2005 ships. We'll try to keep you up to date with all the changes, update the book's code examples, and post some additional samples on the book's Web site. Look for pointers to the code and updates at the following locations:
Yukon has all the stuff that I'd read about and more. At a SQL*PASS conference, I ran into Roger Wolter, a friend from the SQL Server team. We'd originally met when I was speaking at a Web Services conference on SQLXML Web Services in SQL Server 2000 Web Release 3. Li did I know that Roger, the "owner" of this feature, was in the audience. He said he liked the talk; I was relieved. When we met again at SQL*PASS, I asked Roger about Web Services in Yukon, and he told me about his latest project, called SQL Server Service Broker. It sounded to me like an implementation of a Web Service-like concept built over the robustness of a queuing system, built on top of the robustness of a database. Otherwise, his recollection of the meeting is about the same as mine. I was further intrigued.
So far I've mentioned Service Broker, Transact-SQL enhancements, security, .NET-based procedures, functions and user-defined types, built-in XML data type and queries, and Web Services. What else could there possibly be for developers? Most developers spend the greatest percentage of their time not in SQL Server Management Studio, but in Visual Studio 2005, writing the client front end. Many developers know the database engine and how to get the most out of it as well as race car drivers know how to get that last bit of speed out of their cars. Developers and application designers,as well as DBAs, must know how the new features work. In the case of snapshot isolation (versioning) or the XML data type, it could drastically affect how they design and write the application. With Service Broker, it opens a whole new raft of scalability choices that simply weren't there before. The last part of this book talks about client and application server features enabled either inside or outside SQL Server itself. The enabling technologies outside the database are ADO.NET's SqlClient and the client-side XML stack featuring its own XQuery engine. Client-side XQuery works against XML documents on the file system, against SQLServer, or both at the same time.
Finally, there are those developers who would rather not know that the database exists at all. They deal in objects and would just like to call "Load" and "Save" on their object model and have it taken care of. They're more interested in their business or application domain than in how to create a distributed partitioned view to spread the Customer table over multiple SQL Server instances. They see only Customer instances and collections. For these folks, ObjectSpaces and Microsoft Business Framework are what float their boat in this release. In addition to being able to persist their instances, they want "Load" and "Save" to take nanoseconds. ObjectSpaces was designed with optimization in mind.
In conclusion, I think there's quite a bit in Yukon for just about every developer, DBA, application designer, business analyst, and data miner. I've read in some trade publications that the new features just aren't that interesting; they're more like a recitation of glitzy acronyms than substance. This may be the initial perception, but let's rewind to mid-1981. I'm working for an insurance company in Seattle, and we're planning to convert our indexed file data, which we'd just converted from ISAM (indexed sequential access method) to VSAM (virtual storage access method), to a better, more robust database engine. The one we had in mind was IMS (IBM's Information Management System product). The salesperson, however, wants us to look at some new-fangled database they call SQL/DS (which eventually became DB2). After designing some tables and playing around with some queries, we asked some tough questions like "Why does it matter that a database engine is built on a mathematical theory?" and "Why would you want to learn a foreign query language called SQL rather than using nice, fast assembly language or COBOL programs?" and "Why did you just decompose our 2 nice, understandable records into 30 little tables just to join them back together again?" and "Why does it go so slow?" It was the beginning of the relational era. Relational engines weren't all that optimized yet, and smart programmers with fast disks could beat the engine every time. In 1981 we sent the product back, and I didn't learn SQL until 1987. By then I was a bit behind on the learning curve, but relational engines were a heck of a lot faster, and programmers wrote a little SQL and much less procedural code. And they got much more work done. So I smile when I see folks shake their head about the XML data models or the XQuery Formal Semantics. I saw the same raised eyebrows when mixing object-oriented concepts and data first came on the scene. Maybe the head-shakers are right, but I'm not waiting until 2010 to learn XQuery. It doesn't matter whether you choose to wait, however, or use relational exclusively. Yukon and .NET 2.0 have the enabling engines for all these data storage and query technologies—and more.
Bob BeaucheminPortland, Oregon, March 2004
Introduction
Transact SQL serves us developers well all these years and still continues to work quite well, thank you. This book lists the enhancements to this procedural dialect of SQL and that chapter ended up to be much longer (because of the number of enhancements) than I originally thought. In the last few years I'd been spending a lot of time in the XML space and done a lot of thinking about the differences and similarities between the XML and relational models. I liked the formal W3C standardization process for XML, slow as it seems at times. I started to investigate the ANSI SQL standards in earnest, though I'd read them before, and realized that SQL has a rich and deep foundation, starting with SQL:1986 up to the last mainstream standard, SQL:1992. And past that to SQL:1999. But in 2002 there were specifications in progressto define how XML would be integrated into a relational database. There was a synergy with the XML work I'd been doing lately. I heard there would be XML functionality in Yukon, including an XML data type, XML schema validation, and an implementation of the emerging standard query language for XML, XQuery.
In addition, beginning with the object-oriented graphic user interface on the NeXT computer, I'd spent a lot of the last ten years, using object-oriented techniques. And Yukon promised to integrate the .NET runtime into the database engine itself. Not that SQL Server internals were to be written in .NET, but that .NET would be directly accessible as a language for stored procedures and user-defined functions. I could use object-oriented programming techniques with my database programming as well. This might be a big assist to the procedural programming in T-SQL I was already doing, in those cases where I needed it. It's read about using object-oriented languages in the ANSI SQL specifications. Finally, there was the rumor that .NET classes might be available in SQL Server as types that the server knew about. I'd read the ANSI spec for that too. I just had to see this product.
So we've have been working on writing this book since late 2002, when I met with Eric Brown in Redmond and we got the OK and the software. Since 2002 we'd badgered the SQL Server and Webdata teams with copious questions about not only how the software worked but why it was designed that way. They were very understanding about our persistence, but sometimes I felt like I was being a bit of a pest. When we started to teach the class in earnest, we tried to pay them back with information about how software vendors and others thought the features would be useful. At that time, Niels and I were writing and Dan was reviewing and making suggestions, however Dan got hooked too. We almost published in the Beta 1 timeframe, but held back. There were too many major enhancements to the way things actually worked, and we'd written about how things worked too early. Readers would think things worked the old way instead of the improved way. And there were more enhancements coming in beta 2. We held off writing and went for another revision. We were permitted, however, to write and teach a class to early adopters, based on the current state of our work and of the product. I think we've taught about 400-500 students as of this writing. The product evolved. More revisions. I'd told Mary that I was "almost done" so many times that she shook her head and laughed when I mentioned I might really be done again five minutes ago. It's certainly possible that some of the features or the implementation of them could change between now and when SQL Server 2005 ships. We'll try and keep you up to date with all the changes, update the book's code examples, and post some additional samples on the book's website.
Yukon has all the stuff that I'd read about and more. At a SQL*PASS conference I ran into Roger Wolter, a friend from the SQL Server team. We'd originally met when I was speaking at a Web Services conference on SQLXML Web Services in SQL Server 2000 Web Release 3. Little did I know that Roger, the "owner" of this feature was in the audience. He said he liked the talk, I was relieved. When we met again at SQL*PASS, I asked Roger about Web Services in Yukon and he told me about his latest project, called SQL Server Service Broker. It sounded to me like an implementation of a Web Service-like concept built over the robustness of a queuing system, built on top of the robustness of a database. Otherwise, his recollection of the meeting is about the same as mine. I was further intrigued.
So far I've mentioned service broker, Transact-SQL enhancements, security, .NET-base procedures, functions and user-defined types, built-in XML data type and queries, and Web Services. What else could there possibly be for developers? Most developers spend the greatest percentage of their time not in SQL Server Management Studio, but in Visual Studio 2005, writing the client front-end. Many developers know the database engine and how to get the most out of it as well as race car drivers know how to get that last bit of speed out of their cars. Developers and application designers, as well as DBAs must know how the new features work. In the case of snapshot isolation (versioning) or the XML data type, it could drastically affect how they design and write the application. With Service Broker, it opens up a whole new raft of scalability choices that simply weren't there before. The last parts of this book talks about client and application server features enabled either inside or outside SQL Server itself. The enabling technologies outside the database are ADO.NET's SqlClient and the client-side XML stack featuring its own XQuery engine. Client-side XQuery works against XML documents on the file system, against SQL Server or both at the same time.
Finally, there are those developers who would rather not know that the database exists at all. They deal in objects and would just like the call "Load" and "Save" on their object model and have it taken care of. They're more interested in their business or application domain than in how to create a distributed partitioned view to spread the Customer table over multiple SQL Server instances. They see only Customer instances and collections. For these folks, ObjectSpaces and Microsoft Business Framework is what floats their boat in this release. In addition to being able to persist their instances, they want "Load" and "Save" to take nanoseconds. ObjectSpaces was designed with optimization in mind.
In conclusion, I think there's quite a bit in Yukon for just about every developer, DBA, application designer, business analyst, and data miner. I've read in some trade publications that the new features just aren't that interesting; they're more like a recitation of glitzy acronyms than substance. This may be the initial perception, but let's rewind back to mid-1981. I'm working for an insurance company in Seattle, Washington and we're planning to convert our indexed file data, which we'd just converted from ISAM (indexed sequential access method) to VSAM (virtual storage access method) to a better, more robust, database engine. The one we had in mind was IMS (IBM's Information Management System product). The salesperson, however, wants us to look at some new-fangled database they call SQL/DS (which eventually became DB2). After designing some tables and playing around with some queries, we asked some tough questions like "why does it matter that a database engine is built on a mathematical theory" and "why would you want to learn a foreign query language called SQL rather than using nice fast assembly language or COBOL programs" and "why did you just decompose our 2 nice understandable records into 30 little tables just to join them back together again" and "why does it go so slow"? It was the beginning of the relational era. Relational engines weren't all that optimized yet and smart programmers with fast disks could beat the engine every time. In 1981 we sent the product back, and I didn't learn SQL until 1987. By then I was a bit behind on the learning curve, but relational engines were a heck of a lot faster and programmer wrote a little SQL and much less procedural code. And they got much more work done. So I smile when I see folks shake their head about the XML data models or the XQuery Formal Semantics. I saw the same raised eyebrows when mixing object-oriented concepts and data first came on the scene. Maybe the head shakers are right, but I'm not waiting until 2010 to learn XQuery. It doesn't matter if you choose to wait, however, or use relational exclusively. Yukon and .NET 2.0 have the enabling engines for all of these data storage and query technologies and more.