The Guru's Guide to Transact-SQL
Ken Henderson · CERN Document Server (European Organization for Nuclear Research) · 2000
From Book: This is coder's book. It's intended to help developers build applications that make use of Transact-SQL. It's not about database administration or design. It's not about end-user or GUI application development. It's not even about server or database performance tuning. It's about developing best Transact-SQL code possible, regardless of application. When I began writing this book, I had these design goals in mind: Be very generous with code samples--don't just tell readers how to do something, show them. Include complete code samples within chapter texts so that book can be read through without requiring computer or CD-ROM. Use modern coding techniques, with specific emphases on ANSI compliance and current version features and enhancements. Construct chapters so that they're self-contained--so that they rely as little as possible on objects created in other chapters. Provide real-world code samples that have intrinsic value apart from book. Avoid rehashing what's already covered extensively in SQL Server Books Online. Highlight aspects of Transact-SQL that differentiate it from other SQL dialects; don't just write another ANSI SQL book. Avoid excessive screenshots and other types of filler mechanisms often seen in computer books. Proceed from simple to complex within each chapter and throughout book. Provide an easygoing, relaxed commentary with de-emphasis on formality. Be reader's indulgent, amiable tutor. Attempt to communicate in writing way that people speak. You'll have to judge for yourself whether these goals have been met, but my hope is that, regardless of degree of success, effort will at least be evident. About Sample Databases This book uses SQL Server's Northwind and pubs sample databases extensively. You'll nearly always be able to determine which database particular example uses from surrounding commentary or from code itself. The pubs database is used more often than Northwind, so, when not otherwise specified or when in doubt, use pubs. Usually, modifications to these databases are made within transactions so that they can be reversed; however, for safety's sake, you should probably drop and recreate them after each chapter in which they're modified. The scripts to rebuild them (instnwnd.sql and instpubs.sql) can be found in \Install subdirectory under root SQL Server folder. Results Abridged If I have pet peeve about computer books, shameless use of space-filling devices to lengthen them--the dirty little secret of computer publishing industry. Many technical books these days overflow with gratuitous helpings of screenshots, charts, diagrams, outlines, sidebars, icons, line art, etc. There are people who assign more value to book that's heavy, and many authors and publishers have been all too happy to accommodate them. They seem to take old saying that a picture is worth thousand words literally--in some cases turning out books that are little more than picture books. I think there's point at which comprehensiveness gives way to corpulence, time when exhaustiveness becomes exhausting. In this book, I've tried to strike balance between being thorough and being space-efficient. To that end, I've often truncated or clipped query result sets, especially those too wide to fit on page and those of excessive length (I always point this out). On occasion I also list them using reduced font sizes. I don't include screenshots unless doing so benefits discussion at hand materially (only one chapter contains any screenshots). This is in keeping with my design goal of being complete without being overwrought. Nearly 600 SQL scripts are used in this book, and they are all included in chapters that reference them. Hopefully none of abridgements will detract from book's overall usefulness or value. On Formality Another of my pet peeves is formality for sake of formality. An artist once observed that it's harder to draw good curved line than straight What he meant was that in some ways more difficult to do something well for which there is no exact or stringent standard than to do something that's governed by explicit rules and stuffy precedents. All you have to do to draw straight line is pick up straightedge. The rules that govern formal writing, particularly that of academic variety, make writing certain kinds of books easier because they convert much of subjective nature of writing into something more objective. They're like training wheels on would-be author's bicycle. Writing goes from being creative process to mechanical one. Cross all T's, dot all I's, and you're halfway there. Obviously, this relieves author of many of decisions that shape creative writing. It also turns otherwise good pieces of work into dreary, textbook-like dissertations that are about as interesting as telephone book White Pages. So, I reject notion that formal writing is better writing, that it is higher standard and is ideal for which all technical writers should strive. Instead, I come from Mark Twain school of thought--I eschew surplusage--and I believe that, so long as common methods of speech do not become overly banal (a subjective distinction, I freely admit), ultimate goal of technical writer should be to write way that readers speak. It is way people--even technical people--are most accustomed to communicating and way they are most able to learn and share ideas. I did not invent this way of thinking; simply way most of my favorite authors--Mark Twain, Dean Koontz, Joe Celko, Ernest Hemingway, Robert Heinlein, Andrew Miller, Oscar Wilde, P. J. O'Rourke, Patricia O'Connor--write. Though it is far more difficult to structure and write narrative that flows naturally and reads easily, worth effort if ideas writer seeks to convey are understood as they were intended. So, throughout this book, you'll see number of rules and pseudo rules of formal writing stretched, skirted, bent, and sometimes outright broken. This is intentional. Sometimes I split infinitives, begin sentences with conjunctions, and end them with prepositions. Sometimes record is used interchangeably with row; sometimes field takes place of column; and I never, ever treat data as plural word. I saw some software recently that displayed message to effect the data are being loaded, and I literally laughed out loud. The distinction between plural data and its obscure singular form datum is not maintained in spoken language and hasn't really ever been (except, perhaps, in ancient Rome). It has also been deprecated by numerous writing guides and many authors. You will have to look very hard for an author who treats data as plural word (I can think of only one off top of my head, irascible Ted Codd). The tendency for technical communication to become self-important or ostentatious has always baffled me: why stoop to pretension? Why trade fluid conveyance of ideas between people for nonsense that confuses some and reads like petty one-upmanship to others? Acknowledgments I'd like to thank my wife, who not only makes it possible for me to write books but also makes it worthwhile. The book you see before you is as much hers as it is mine. I'd like to thank Neil Coy, who made real programmer of me many years ago. Under Neil's tutelage, I learned software craftsmanship from master. Joe Celko, dean of SQL language, has been good friend and valuable source of information throughout this project. Kudos to John Sarapata and Thomas Holaday for helping me come up with title for book (I'll keep Sybase for Dummies in mind for future use, John). Thanks to book's technical reviewers, particularly Wayne Snyder, Gianluca Hotz, Paul Olivieri, and Ron Talmage. Heartfelt thanks to John Gmuender, Joe Gallagher, Mike Massing, and Danny Thorpe for their equanimity and for keeping me sane through recent storm. Congratulations and genuine appreciation to superb team at Addison-Wesley--Michael Slaughter, Marisa Meltzer, J. Carter Shanklin, and others too numerous to list. Special thanks to Nancy Cara-Sager, friend, technical reviewer, and copyeditor who's been with me through several books and couple of publishers now. Her tireless attention to detail has saved me from embarrassing myself more times than I can count.