Character Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619 char[(length)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619 varchar[(length)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 varchar(max) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621 text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622 Unicode Character Strings: nchar, nvarchar, nvarchar(max), ntext . . . . . 622 Binary Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 binary[(length)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 varbinary[(length)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624 varbinary(max) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624 image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 Other Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 rowversion (a.k.a. timestamp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 uniqueidentifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626 cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629 table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629 sql_variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632 Not Simply Scalar Datatypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633 ■ INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635 ■ CONTENTSxiv 8662FM.qxp 7/28/08 6:19 PM Page xiv Foreword D atabase design is a passion that Louis and I share. This fall, I will be fortunate to share a stage with my friend, Louis Davidson. We’re copresenting at DevLink in Louis’s hometown of Nashville and then again at PASS in Seattle. Both times, we’ll discuss, debate, and celebrate the topic of database design and how critical it is for any datacentric application. Database design is part science and part art. There’s a science to normalization, but determining the scope of the entity is an art form best learned from working with a broad repertoire of databases. There’s a simple beauty to an elegant solution. Louis is more than an author or database designer ; Louis is a master artisan, and in this book, you’ll discover hidden within the words a call to improve your craft, to sculpt databases that stand the test of time, and to create vir tual worlds of data that enable developers to play their best game. Database design is the foundation of every datacentric application. An elegant database design makes the data obvious and easy to query and sets up the developer for success with efficient set- based queries. But, no amount of code can compensate for a poor database design or add features missing from the database. No role is more critical to any datacentric application than the role of the data modeler. User interfaces come and go, but data lasts for generations of application lan- guages, and today’s database schema errors will be cursed by programmers not yet born using languages and tools not yet invented. It’s worth spending a little extra time to polish your database design under the tutelage of my good friend, Louis. So it’s with great pleasure that I welcome you to this third edition of Louis’s field guide to the greatest job in the world of software. Paul Nielsen SQL Server MVP xv 8662FM.qxp 7/28/08 6:19 PM Page xv 8662FM.qxp 7/28/08 6:19 PM Page xvi About the Author ■ LOUIS DAVIDSON has over 15 years of experience as a corporate database developer and architect. Currently, he is the data architect for the Christ- ian Broadcasting Network and NorthStar Studios in Nashville, Tennessee. Nearly all of Louis’s professional experience has been with Microsoft SQL Server, from the early days to the latest version currently in beta. Louis has been the principal author on four editions of a book on database design. Louis’s primary areas of interest are database architecture and coding in T-SQL, and he has experience designing many databases and writing thousands of stored procedures and triggers through the years. About the Contributing Authors ■ KEVIN KLINE is the technical strategy manager for SQL Server solutions at Quest Software. A Microsoft SQL Server MVP since 2004, Kevin is a founding board member and past president of the international Professional Associa- tion for SQL Server (PASS). He has written or cowritten several books including SQL in a Nutshell (O’Reilly, 2004), Pro SQL Server 2005 Database Design and Optimization (Apress, 2006), and Database Benchmarking: Practical Methods for Oracle & SQL Server (Rampant, 2007). Kevin contributes to SQL Server Magazine and Database Trends and Applications and blogs at SQLBlog.com and SQLMag.com. Kevin is also a top-rated speaker at confer- ences worldwide, such as Microsoft Tech Ed, the PASS Community Summit, Microsoft IT Forum, DevTeach, and SQL Connections, and has been active in the IT industry since 1986. ■ SCO TT KLEIN is an independent consultant with a passion for all things SQL Server, .NET, and XML. He is the author of several books, including Professional SQL Server 2005 XML (Wrox, 2006) and Professional LINQ (Wrox, 2008), and he wr ites the biw eekly feature article for the SQL P ASS Community Connector . H e has also contr ibuted ar ticles for sev er al w eb sites, including Wrox ( http://www.wrox.com) and TopXML (http://www.topxml.com). He fre- quently speaks to SQL Server and .NET user groups around Florida. Scott lives in W ellington, Florida, and when he is not sitting in front of a computer, he can be found hanging out with his family or aboard his Yamaha at the local motocross track. He can be reached at ScottKlein@SqlXml.com. ■ KURT WINDISCH is the applications supervisor for the internal IT department at Levi, R ay, and Shoup, Inc., a global provider of technology solutions with headquarters in Springfield, Illinois. He has more than 17 years of experience in the IT industry. He spent five years serving on the board of directors for the Professional Association for SQL Server, has written for several SQL Server magazines , and has pr esented at confer ences internationally on the topic of database programming with SQL Server. xvii 8662FM.qxp 7/28/08 6:19 PM Page xvii 8662FM.qxp 7/28/08 6:19 PM Page xviii About the Technical Reviewers ■ WAYNE SNYDER is recognized worldwide as a SQL Server expert and Microsoft Most Valued Professional (MVP), and he has over 25 years of experience in project management, database administration, software design, performance measurement, and capacity planning. He is a sought-after speaker, consultant, writer, and trainer. Wayne is the current president of the Professional Association for SQL Server (PASS) ( www.sqlpass.org) and a managing consultant for Mariner, a business intelligence company ( www.mariner-usa.com). He also plays keyboard for a regional cover band named SoundBarrier ( www.soundbarrierband.com). ■ EVAN TERRY is a lead consultant working at The Clegg Company, specializing in data modeling, data quality, and information management. His past and current clients include the State of Idaho; Albertsons; American Honda Motors; and Toyota Motor Sales, USA. He is the coauthor of Apress’s Beginning R elational Data Modeling (2005) and was a presenter at the 2006 and 2007 IAIDQ confer - ences and at the 2008 DAMA International Conference on the subject of data quality. He can be reached at evan_terry@cleggcompany.com. ■ DON WATTERS is a Staff Software Engineer at the Walt Disney Internet Group in Seattle, Washington. He has been working on Microsoft SQL Server products since version 6.5, and has over 10 years of experience with the product. He has extensive administrative and developer experience with very large OLTP and OLAP systems and enjoys learning and applying his knowledge to new and interest- ing database challenges. In his free time, Don enjoys spending time with his children, playing music and video games, and of course, studying all things related to Microsoft SQL Server. He can be reached at DonRWatters@aol.com. xix 8662FM.qxp 7/28/08 6:19 PM Page xix 8662FM.qxp 7/28/08 6:19 PM Page xx Acknowledgments If I have seen further, it is by standing on the shoulders of giants. —Sir Isaac Newton I am not a genius, nor am I some form of pioneer in the database design world. I acknowledge that the following “people” have been extremely helpful in making this book happen. Some helped me directly, while others probably don’t even know that this book exists. Either way, they have all been an important part of the process. Far above anyone else, Jesus Christ, without whom I wouldn’t have had the strength to com- plete the task of writing this book: I know I am not ever worthy of the love that You give me. My wife Valerie Davidson and daughter Amanda Davidson for putting up with this craziness for a fourth time (and helping me with the picture for the co ver). My mom for just being there to keep me entertained with information about the world around her, and my mother-in-law, too, for helping us out at times. My best friend in the world who got me started with computers back in college when I still wanted to be a mathematician. I miss him far more than he will probably ever know; some day, I need to find him again and thank him wher e he might actually see it. My mentors Mike Farmer, Chip Broecker, and Don Plaster for the leadership they gave me in my early years. Gary Cornell for giving me a chance to write the book that I wanted to write. Frank Castora and Don Watters for doing beta reads of the book on their own time. (Don later became a full technical editor on the book!) Evan Terry and Wayne Snider for their technical edits, even if the process when a little off center and didn’t end up as we started. My current manager Rob Murdoch for giving me time to go to several conferences that really helped me to produce as good of a book as I did. All of my coworkers at CBN and the now- defunct Compass, who gave me many examples for the book. Scott Klein, Kevin Kline, and Kurt Windisch for taking up the slack with topics I didn’t want to (OK, couldn ’ t) tackle. Paul Nielsen for offering and taking the time to write a foreword to this book. The fantastic editing staff I’ve had, including Jonathan Gennick who (figuratively) busted my lip a few times over my poor use of the English language and without whom the writing would sometimes appear to come from an illiterate baboon. Most of these people are included on the copyright page, but I want to say a specific thanks to Tony Davis (who had a big hand in the book last time) for making this book gr eat, despite my fr equently r ambling wr iting style . Raul G arcia , who wor ks on the Microsoft SQL Server Engine team, for information about using EXECUTE AS and certificate-based security. Isaac Kunen for the discussions at Tech Ed that helped me understand spatial datatypes better. James Manning for the advice on READ COMMITTED SNAPSHOT. xxi 8662FM.qxp 7/28/08 6:19 PM Page xxi Chuck Heinzelman for being such a good friend and giving me the chance to write the article for SQL Server Standard around the time of this book coming out. All the MVPs that I’ve worked with over the past year and a half. Never a better group of folks have I found. Steven Dybing, Ben Miller, and now Ali Brooks have been great to work with. I want to list a few others individually for things they’ve specifically done to help me out: Dejan Sarka and Andrew Watt reviewed the previous version of the book with incredible vigor and didn’t let me slide on even small points. Hugo Kornelis gave me the most negative criticism of the previous version of the book; he really opened my eyes to some of the weaknesses (if only I could have gotten him to as one of the technical reviewers!). Steve Kass gave me the code for demonstrating what’s wrong with the money datatypes, as well as cool solutions to problems in newsgroups that made me think. Erland Somarskog helped me understand a bit more about how error handling works, and many other topics (not to mention providing his great website, http://www.sommarskog.se/). Adam Machanic helped me with many topics on my blog and in newsgroups. Aaron Bertrand deserves thanks for his great website http://www.aspfaq.com and the shoe memories. Thanks to Kalen Delaney for all she has done for me and the community and to Dr. Greg Low for putting me on his http://www.sqldownunder.com podcast. Kim Tripp provided a wonderful paper on SNAPSHOT isolation levels, and Arnie Rowland got me the two gigs with Microsoft Learning that helped me out in parts of the book. Thanks to Allen White for the times at Tech Ed and the horrible interview and to Jason F ollas for the time at Tech Ed where I listened to you talking about the spatial types. I also want to thank Tony Bain, Hillary Cotter , Mike Epprecht, Geoff Hiten, Tom Moreau, Andrew Kelly, Tony Rogerson, Linchi Shea, Paul Nielson , Tibor Karaszi, Greg Linwood, Peter Debetta, Dr. Tom Moreau, Dan Guzman, Jacco Schalkwijk , Anith Sen, Jasper Smith, Ron Talmage, Christian Lefter, and Kent Tegels, because all of you have specifically helped me out over the past years in the newsgroups, teaching me new things to make my book far better. To the academics out there who have permeated my mind with database theory, such as E. F. Codd, Chris Date, Fabian Pascal, Joe Celko, my professors at the University of Tennessee at Chattanooga, and many others: I wouldn’t know half as much without you. And thanks to Mr. Date for reviewing Chapter 1; you pr obably did more for the next version of this book than the current one. And to Jim Gray and Ken Henderson, who both were amazing advocates of SQL Server and have inspired me over the years. Even with this large number of folks I have mentioned here, I am afraid I may have missed someone. If so, thank you! Louis Davidson ■ ACKNOWLEDGMENTSxxii 8662FM.qxp 7/28/08 6:19 PM Page xxii Introduction I often ask myself, “Why do I do this? Why am I writing another edition of this book? Is it worth it? Couldn’t I help Mario save the princess faster if I just chucked the book and played Nintendo?” These questions were answered again for me by a fellow MVP at the Microsoft MVP Summit in 2008. He thanked me for writing this book and said that he’d tried to read the academic books on the subject and they were hard for him to follow. “Oh yeah,” I thought, “that was why I started out to do this thing in the first place.” When I was first getting started designing databases, I learned from a few gr eat mentors , but as I wanted to progress, I started looking for material on database design, and there wasn’t much around. The best book I found was Chris Date’s An Introduction to Database S ystems (Addison Wesley, 2003), and I read as much as I could comprehend. The problem, however, was that I quickly got lost and started getting frustrated that I couldn’t readily translate the theory of it all into a design process that really is quite simple once you get the ideas down. In Chris’s book, and in other textbooks I had used, it became clear that a lot of theory, and even more math, went into creating the relational model. If you want to be a theorist, Chris’s book is essential reading, along with lots of other books (here is a good place to start looking for more titles: http://www.dbdebunk.com/books.html). The problem is that most of these books have far more theory than the average practitioner wants (or will take the time to read), and they don’t really get into the actual implementation of a real database system. My book’s goal is simply to fill that void and bridge the gap between academic textbooks and the purely implementation-oriented books that are commonly written on SQL Server—my intention is not to knock those books, not at all; I have numerous versions of those types of books on my shelf. This book is more of a technique-oriented book than a how-to book teaching you the features of SQL Server. I will cover many the most typical features of the relational engine, giving you techniques to work with. I can’t, however, promise that this will be the only book you need on your shelf. If you have previous editions of this book, you might question why you need this edition, and I know the feeling. I spent a lot of time trying to figure out why you should buy this new edition, and my reason isn’t the obvious one—that now I cover 2008 features. Clearly, that is a part of it, but the biggest thing is that I continue to come up with new content to make your job easier. I’ve added another chapter about patterns of development (Chapter 7), and every chapter has a good amount of new material to help enhance your database designs. O scar W ilde, the poet and playwright, once said, “I am not young enough to know everything.” I t is with some chagr in that I must look back at the past and r ealiz e that I thought I knew ev er ything just before I wrote my first book, Professional SQL Server 2000 Database Design. It was ignorant, unbridled, unbounded enthusiasm that gave me the guts to write the first book. In the end, I did wr ite that first edition, and it was a decent enough book, lar gely due to the beating I took from my technical editing staff. And if I hadn’t possessed the enthusiasm initially that drove me to finish, I likely would not be wr iting this four th edition of the book. H owever, if you had a few weeks to burn and you went back and compared each edition of this book, chapter by chapter, section by section, to the current edition, you would notice a progression of material and a definite maturing of the writer. Ther e ar e a few r easons for this pr ogr ession and maturity. One reason is the editorial staff I have had over the past two versions: first Tony Davis and now Jonathan Gennick. Both of them were very tough on my writing style and did wonders for the structure of the book. Another reason is simply xxiii 8662FM.qxp 7/28/08 6:19 PM Page xxiii [...]... that problem, because I could sell a million books with just that This book will assist you with some techniques and processes that will help you through the process of designing databases, in a way that’s clear enough for novices and helpful to even the most seasoned professional This process of designing and architecting the storage of data belongs to a different role from those of database setup and. .. this design process in earnest, you need to explore a few core relational database concepts Therefore, this chapter discusses the following topic areas: 1 8662Ch01.qxp 2 7/28/08 3:37 PM Page 2 CHAPTER 1 s INTRODUCTION TO DATABASE CONCEPTS • Database design phases: The next section provides an overview of the four major phases of relational database design: conceptual, logical, implementation, and physical... important data in a database designed by someone who didn’t understand the fundamentals of database design? The first four chapters of this book are devoted to the distinct phases of relational database design and how to carry out each phase effectively so you are able to arrive at a final design that can fulfill the business requirements and ensure the integrity of the data in your database However,... fundamental database objects, including the database itself, as well as tables, columns, and keys These objects are likely familiar to most, but there are some common misunderstandings in their usage that can make the difference between a mediocre design and a high-class, professional design In particular, misunderstanding the vital role of keys in the database can lead to severe data integrity issues and. .. physical For time and budget reasons, it is often tempting to skip the earlier database design phases and move straight to the implementation phase This chapter will explain why skipping any or all of these phases can lead to an incomplete and/ or incorrect design, as well as one that does not support high-performance querying and reporting • Relational data structures: This chapter will provide concise... continue to keep my e-mail address available (louis@drsql.org), and you can leave anonymous feedback on my website if you want (drsql.org) You will also find an addendum there that covers any material that I wish I had known at the time of this writing Purpose of Database Design What is the purpose of database design? Why the heck should you care? The main reason is that a properly designed database is straightforward... blog (http://sqlblog.com/blogs/louis_davidson) with the tag DesignBook as well as to my website (http://drsql.org/ProSQLServerDatabaseDesign.aspx) I’ll be putting more information in both places as it becomes available pertaining to new ideas, goof ups I find, or additional materials that I choose to publish because I think of them once this book is no longer a jumble of bits and bytes and is an actual... primary driver for all projects Couple that with the fact that there are usually many times more functional programmers waiting on the database, all telling management that they can’t do anything until the database is designed and at least started to be implemented If that isn’t enough, this is about the time that a little inaccuracy infects the mind-set of the project team: Database design is not that... the database design and implementation process is to step beyond the structures and consider how to maximize resource utilization among many users In this chapter, I describe several strategies for how to implement concurrency in your data access and modification code Chapter 11: Considering Data Access Strategies: In this chapter, many of the concepts and concerns of writing code that accesses SQL Server. .. reporting requirements, and, most crucial of all, the integrity of the data I admit it is easy to succumb to quick versus good when you have a manager breathing coffee breath on the back of your neck every 10 minutes asking, “Done yet?” The problem with this mind-set is that obvious things are commonly missed, and late in the project you have to go back and tweak (and re-tweak) the design, and often tweaking . Oracle & SQL Server (Rampant, 2007). Kevin contributes to SQL Server Magazine and Database Trends and Applications and blogs at SQLBlog.com and SQLMag.com several books including SQL in a Nutshell (O’Reilly, 2004), Pro SQL Server 2005 Database Design and Optimization (Apress, 2006), and Database Benchmarking: