Preface to the First Edition

For me, Microsoft SQL Server has been a labor of love. I lived and breathed this product for years, and I look at it not unlike how I look at my childrenwith immense love and pride . I've helped nurture the product from its infancy, through some very tough years , to its current success. I've lost many nights' sleep, upset that some customer was disappointed with it. Fortunately, I've also had many more thrills and moments of rejoicinglike when a customer speaks glowingly of SQL Server or when we win another award. Yes, the analogy to a child is the closest thing I can think of to describe my feelings about SQL Server. Like people who have always thought that one day they'd write the Great American Novel, I felt a need to finally put down in words some hopefully unique knowledge and opinions I have regarding SQL Server.

This book is not an introductory treatise on SQL Server, although it does include one introductory chapter (Chapter 2). In Chapter 1, I discuss the history of the product (which I lived), from SQL Server's inception and partnership with Sybase to its current success. But beyond these early chapters, the book is very detailed and written for those who want to dig deeply into SQL Server. This book is a suitable read for those who have worked with SQL Server for years already. It will also be of interest to experienced database professionals new to SQL Server who are developing or considering new development projects.

In this book, I focus on the "back-end" capabilities of the database engine. Topics include choosing appropriate hardware for SQL Server, effective use of the SQL language, writing correct queries, common mistakes, consistency and concurrency tradeoffs, data storage and structures, locking, and scrollable cursors . Performance considerations are covered throughout the book. The final chapters (Chapters 14 and 15) discuss specific performance issues, but because they assume that you've gained much knowledge from reading earlier chapters in the book, I strongly discourage you from jumping directly to those chapters.

When I planned the book, I felt it was necessary to describe how SQL Server works before going into the product's functional capabilities. But that presents a "chicken-or-the-egg" problem: what should I introduce first? I decided to include architectural information near the beginning of the bookChapter 3 provides an in-depth discussion of how SQL Server works. If you are already familiar with the functional aspects of SQL Server, I think you'll benefit most from this chapter. If you are new to SQL Server, I encourage you to go back and read Chapter 3 again in a couple months after you've gained more familiarity with the product. I think you'll get a lot more out of it. Initially, simply try to absorb just the basics.

I've included little discussion of client programming issues, such as which development tools to use or details about ODBC programming. If you need information about these topics, see the Suggested Reading section near the end of the book. And I'm sorry to say that there is little discussion of the replication capabilities of SQL Server. (This is also a little embarrassing because I recently took charge of managing the Replication Unit within the SQL Server development team.) But, like software, this thing had to eventually ship, and replication ended up on the "cut" list. I promise that we're doing so many exciting new things in replication for the next version that I knew I would have to almost completely rewrite any replication section before long anyway. (And a very good whitepaper about SQL Server replication capabilities is included on the companion CD.)

This book has a healthy smattering of my personal opinions about many issues in software and database development. Software development is still at least as much an art as a science, and there are different schools of thought and different approaches. Healthy, even if heated, debate is one of the things that make software development so much fun. I elected to be pretty candid and direct with my opinions in many places, rather than keep the book bland and neutral. Some people will no doubt disagree strongly with some of my opinions. That's fine. I respect your right to disagree. But I do hope you can read and accept the book for its overall merits, even if you disagree with a few topics. And, of course, the opinions I present here are mine alone and not necessarily those of Microsoft.

Now I have many people to thank. Without the product, there would be no book. So my thanks must first be to my fellow SQL Server "old-timers," who bootstrapped the product. Working with you was an amazing, unforgettable experience. We worked 80 hours a week far more often than not, but we loved it. No one deserves more credit for SQL Server's success than Rick Vicik. I'm sure Rick is a genius, but he has the rare trait among those with genius IQs of being perfectly pragmatic. He's a doer, and no one works harder or more passionately. He led the development team by sheer example. And what a team. Without the other old-timers like Mike Habben, Lale Divringi, Peter Hussey, Chris Cassella, Chris Moffatt, Kaushik Chodhury, Dave Fyffe, Don Reichart, Craig Henry, Jack Love, Karl Johnson, Ted Hart, Gavin Jancke, Dan Tyack, Trish Millines, Mike Ervin, Mike Byther, Glen Barker, Bryan Minugh, and Heidy Krauer, there simply would be no Microsoft SQL Server today. And the early documentation team of Lesley Link and Helen Meyers, and the original marketing team of Dwayne Walker, Gary Voth, and Dan Basica, made SQL Server a product, not just software. It took this unique and special blend of people to make this product and to make it viable . There are, of course, many others of great talent who have joined the SQL Server team during the last few years. But if not for the extraordinary efforts of the original, very small team, there would be no SQL Server now. Be proud and always remember what we did together. We needed and were backed up by a great customer support team, anchored by Andrea Stoppani, Gary Schroeder, Rande Blackman, Joe Marler, Vaqar Pirzada, Damien Lindauer, and James McDaniel (several of whom are now on the SQL Server development team). You often went above and beyond the call of duty. Thank you.

Turning toward the book, I want to extend special thanks to Lesley Link. Lesley did the huge job of editing this book entirely in her "spare time" (which meant many late nights and early Sunday mornings). She really committed to editing this book because of the pride and ownership she, too, feels in the product. But while I wrote the bulk of the book more or less on a sabbatical leave, Lesley edited while she continued in her more than full-time job as the manager of the SQL Server documentation team. There is no better editor in the business. And thanks to her production team, especially Steven Fulgham, Christine Woodward, Pat Hunter, and Rasa Raisys, for helping prepare the book.

Thank you to those who provided invaluable technical reviews of various sections, especially to Jim Gray, Rick Vicik, Mike Habben, Peter Hussey, Don Vilen, Dave Campbell, and Lale Divringi. The mistakes that no doubt remain are mine alone.

Special thanks go to Gary Schroeder, who authored the Microsoft internal documentation for the on-disk data structures that I made use of when describing disk and table formats. And thanks to Betty O'Neil, who revamped and reorganized much of the internal design documentation that I used as a resource when writing.

Finally, thanks to the staff at Microsoft Press: David, Lisa, John, and those of you I never met but knew were there, who guided me through the publication process.

This is the first book I've written. I've shipped a lot more software than books. I've learned there are a lot of similarities. Like the last 10 percent takes 90 percent of the time. And that when it's done, you always have this nagging feeling that you'd like to do some part over and could do it much better the second time around. After all the demands and grief I gave them over the years, I know that the documentation team that formerly reported to me has taken great delight in watching me write and seeing me struggle to complete this work. And just as software is never perfect, neither is this book. I've always found that fact painful in shipping softwareI always want it to be perfect. And I find it painful now. I wish this book were perfect, and I know it's not.

But, as I always remind my development team, "Shipping is a feature." So, after a long labor, I have shipped.

Ron Soukup, 1997