Introduction I AM NOT trying to teach you to program in SQL in this book. You might want to read that again. If that is what you wanted, there are better books. This ought to be the second book you buy, not the first. I assume that you already write SQL at some level and want to get better at it. If you want to learn SQL programming tricks, get a copy of my other book, SQL for Smarties (3rd edition, 2005). I am trying to teach the reader how to work in logical and declarative terms, instead of in a procedural or OO manner—“Query Eye for the Database Guy,” if you will forgive a horrible contemporary pun. Few, if any, SQL programmers came to SQL before learning and writing for years in a procedural or object-oriented language. They then got one particular SQL product and were told to learn it on their own or with a book that has a title like “SQL for Brain-Dead Morons,” “Learn SQL in Ten Easy Lessons or Five Hard Ones,” or worse. This is absurd! It takes at least five years to learn to be a master carpenter or chef. Why would you believe people could become SQL gurus in a weekend? What they become is bad SQL programmers, who speak SQL in dialect from the local SQL product with a strong accent from their previous languages. You might want to read “Teach Yourself Programming in Ten Years” by Peter Norvig (www.norvig.com/21- days.html) or “No Silver Bullets” by Fred Brooks, Computer , 20(4):10- 19, April 1987) to get a reality check. xvi INTRODUCTION The horrible part is that these people often don’t know they are bad programmers. At one extreme, the entire shop where they work is just as bad, and they never see anything else. At the other extreme, if anyone tries to tell them about their problems, they become defensive or angry. If you look at postings on SQL newsgroups, many programmers just want to get a kludge for an immediate problem and not actually obtain a true long-term solution. If these were woodworking newsgroups, their questions would be the equivalent of “What are the best kind of rocks to use to pound screws into fine furniture?” When someone tells them to use large chunks of granite, they are happy, but if you try to tell them about screwdrivers, they explode into a rage. You might want to read an essay on this phenomenon: “Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments” by Justin Kruger and David Dunning (Department of Psychology, Cornell University, www.apa.org/journals/ psp/psp7761121.html). Or look at the actual and self-assessments of American high school students in mathematics and sciences that were part of the Bush administration’s No Child Left Behind Act. 1.1 Purpose of the Book So how did we old farts learn to be better programmers when dinosaurs walked the earth? One of the best helpers we had in the late 1970s when the structured programming revolution came along was a series of books entitled “[Pascal | FORTRAN | COBOL | BASIC] with Style: Programming Proverbs” by Henry Ledgard and some of his colleagues at MIT. The covers were done like a Victorian novel with angels, scrolls, and old-style typographical elements. And like a Victorian novel, the books were subtitled “Principles of Good Programming with Numerous Examples to Improve Programming Style and Proficiency.” These books and others made a big difference for most of us because they taught us how to think like good programmers. My goals in this book are to improve SQL programming style and proficiency. To be more exact: 1. To help an individual programmer write Standard SQL without an accent or a dialect . It is difficult to unlearn old habits but not impossible, and it is best to learn the right way from the start. Amateurs write code for themselves. A professional writes code 1.2 Acknowledgments xvii to be maintained and used by other people. My rule of thumb has been that you need to have a full year of SQL programming before you have your epiphany and suddenly see the world in three: valued logic, data models, and sets. 2. To give an SQL shop a coding standard for internal use . I have tried carefully to give a rationale for each of my rules, and I have given exceptions to those rules when I could think of them. You may disagree with some of my choices, but you will have to provide research and examples to defend your position. It is not good enough to simply declare: “Well, that’s the way we wrote code in FooTran, so it must be the will of God!” as an argument. If you are the team leader, you now have a book (and author) that you can hold up and blame for anything that your people do not like. Even if I am later shown to be wrong about something, you will have been consistent. It is much easier to repair errors if they were made consistently. 3. To give programmers the mental tools to approach a new problem with SQL as their tool . I tell people it takes about a year to “get it” and drop your procedural programming habits. 1.2 Acknowledgments Craig Mullins provided the structure of the chapter on VIEWs in an article in www.DBAzine.com. The formatting style is taken from a house style I have used in CMP magazines and other publications for more than a decade. Peter Gulutzan provided the data for the naming conventions in actual products from an article in www.DBAzine.com. The affix conventions in Chapter 1 are based on internal standards from Teradata Corporation. The scales and measurements and the encoding schemes material appeared in several of my old magazine columns in DBMS and Database Programming & Design before they were collected into a chapter in my book Data & Database (Morgan-Kaufmann Publishers). I have tried to give credit in the text, but so many people have participated in the newsgroups over the years that I know I am forgetting someone. And, obviously, thanks to Henry Ledgard and his “Programming Proverbs” series for the inspiration. I would also like to thank all of the newbie programmers who wrote bad code. It sounds a bit sarcastic, but it is not meant to be. Many of the xviii INTRODUCTION newbies are programmers who were thrown into a DBA or SQL programmer job by management without training or an experienced mentor. I do not want to blame the victims unless they are really not working on getting better. Your errors in syntax, semantics, and style showed me how you were thinking. Diagnosis is the first step to treatment. 1.3 Corrections, Comments, and Future Editions Corrections and additions for future editions can be sent to Morgan- Kaufmann publishers directly or to me at my e-mail address, jcelko212@earthlink.net. CHAPTER 1 Names and Data Elements This is the old joke: “When I was a kid, we had three cats.” “What were their names?” “Cat, cat, and cat.” “That sounds screwed up. How did you tell them apart?” “Who cares? Cats don’t come when you call them anyway!” Y OUR DATA WILL not come when it is called either if you do not give it a name that is always distinct and recognizable. This is an important part of any database project. Bad names for the data elements make the code difficult, or even impossible, to read. I am not kidding about impossible to read. In the old days, software companies used to deliberately scramble source code names and remove formatting to hide the algorithm from the buyers. The tradition seems to linger on, even if not by intent. In August 2004, a SQL newsgroup had a posting in which all of the names were one letter and a long string of digits. There are now ISO-11179 metadata standards that describe rules for naming data elements and for registering standards. Because they are an ISO standard, they are what you should be using in SQL as well as everywhere else. That standard, a bit of typography, and some common sense will give you the rules you need to get started. . I assume that you already write SQL at some level and want to get better at it. If you want to learn SQL programming tricks, get a copy of my other book, SQL for Smarties (3rd edition,. Why would you believe people could become SQL gurus in a weekend? What they become is bad SQL programmers, who speak SQL in dialect from the local SQL product with a strong accent from their. contemporary pun. Few, if any, SQL programmers came to SQL before learning and writing for years in a procedural or object-oriented language. They then got one particular SQL product and were told