SQL Antipatterns: Avoiding the Pitfalls of Database Programming [1 ed.] 1934356557, 9781934356555

Table of contents :
Cover
Table of Contents
1. Introduction
Who This Book Is For
What's in This Book
What's Not in This Book
Conventions
Example Database
Acknowledgments
Part I—Logical Database Design Antipatterns
2. Jaywalking
Objective: Store Multivalue Attributes
Antipattern: Format Comma-Separated Lists
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Create an Intersection Table
3. Naive Trees
Objective: Store and Query Hierarchies
Antipattern: Always Depend on One's Parent
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Use Alternative Tree Models
4. ID Required
Objective: Establish Primary Key Conventions
Antipattern: One Size Fits All
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Tailored to Fit
5. Keyless Entry
Objective: Simplify Database Architecture
Antipattern: Leave Out the Constraints
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Declare Constraints
6. Entity-Attribute-Value
Objective: Support Variable Attributes
Antipattern: Use a Generic Attribute Table
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Model the Subtypes
7. Polymorphic Associations
Objective: Reference Multiple Parents
Antipattern: Use Dual-Purpose Foreign Key
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Simplify the Relationship
8. Multicolumn Attributes
Objective: Store Multivalue Attributes
Antipattern: Create Multiple Columns
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Create Dependent Table
9. Metadata Tribbles
Objective: Support Scalability
Antipattern: Clone Tables or Columns
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Partition and Normalize
Part II—Physical Database Design Antipatterns
10. Rounding Errors
Objective: Use Fractional Numbers Instead of Integers
Antipattern: Use FLOAT Data Type
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Use NUMERIC Data Type
11. 31 Flavors
Objective: Restrict a Column to Specific Values
Antipattern: Specify Values in the Column Definition
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Specify Values in Data
12. Phantom Files
Objective: Store Images or Other Bulky Media
Antipattern: Assume You Must Use Files
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Use BLOB Data Types As Needed
13. Index Shotgun
Objective: Optimize Performance
Antipattern: Using Indexes Without a Plan
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: MENTOR Your Indexes
Part III—Query Antipatterns
14. Fear of the Unknown
Objective: Distinguish Missing Values
Antipattern: Use Null as an Ordinary Value, or Vice Versa
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Use Null as a Unique Value
15. Ambiguous Groups
Objective: Get Row with Greatest Value per Group
Antipattern: Reference Nongrouped Columns
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Use Columns Unambiguously
16. Random Selection
Objective: Fetch a Sample Row
Antipattern: Sort Data Randomly
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: In No Particular Order…
17. Poor Man's Search Engine
Objective: Full-Text Search
Antipattern: Pattern Matching Predicates
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Use the Right Tool for the Job
18. Spaghetti Query
Objective: Decrease SQL Queries
Antipattern: Solve a Complex Problem in One Step
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Divide and Conquer
19. Implicit Columns
Objective: Reduce Typing
Antipattern: a Shortcut That Gets You Lost
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Name Columns Explicitly
Part IV—Application Development Antipatterns
20. Readable Passwords
Objective: Recover or Reset Passwords
Antipattern: Store Password in Plain Text
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Store a Salted Hash of the Password
21. SQL Injection
Objective: Write Dynamic SQL Queries
Antipattern: Execute Unverified Input As Code
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Trust No One
22. Pseudokey Neat-Freak
Objective: Tidy Up the Data
Antipattern: Filling in the Corners
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Get Over It
23. See No Evil
Objective: Write Less Code
Antipattern: Making Bricks Without Straw
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Recover from Errors Gracefully
24. Diplomatic Immunity
Objective: Employ Best Practices
Antipattern: Make SQL a Second-Class Citizen
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: Establish a Big-Tent Culture of Quality
25. Magic Beans
Objective: Simplify Models in MVC
Antipattern: The Model Is an Active Record
How to Recognize the Antipattern
Legitimate Uses of the Antipattern
Solution: The Model Has an Active Record
Part V—Appendixes
A1. Rules of Normalization
What Does Relational Mean?
Myths About Normalization
What Is Normalization?
Common Sense
A2. Bibliography
Index
– SYMBOLS –
– A –
– B –
– C –
– D –
– E –
– F –
– G –
– H –
– I –
– J –
– K –
– L –
– M –
– N –
– O –
– P –
– Q –
– R –
– S –
– T –
– U –
– V –
– W –
– Z –

Citation preview

What Readers Are Saying About

SQL Antipatterns I am a strong advocate of best practices. I prefer to learn from other people’s mistakes. This book is a comprehensive collection of those other people’s mistakes and, quite surprisingly, some of my own. I wish I had read this book sooner. ➤ Marcus Adams Senior Software Engineer Bill has written an engaging, useful, important, and unique book. Software developers will certainly benefit from reading the antipatterns and solutions described here. I immediately applied techniques from this book and improved my applications. Fantastic work! ➤ Frederic Daoud Author of Stripes: ...And Java Web Development Is Fun Again and Getting Started with Apache Click SQL Antipatterns is a must-read for software developers, who will frequently encounter the database design choices presented in this book. It helps development teams to understand the consequences of their database designs and to make the best decisions possible based on requirements, expectations, measurements, and reality. ➤ Darby Felton Cofounder, DevBots Software Development

I really like how Bill has approached this book; it shows his unique style and sense of humor. Those things are really important when discussing potentially dry topics. Bill has succeeded in making the teachings accessible for developers in a good descriptive form, as well as being easy to reference later. In short, this is an excellent new resource for your pragmatic bookshelf! ➤ Arjen Lentz Executive Director of Open Query (http://openquery.com); Coauthor of High Performance MySQL, Second Edition This book is obviously the product of many years of practical experience with SQL databases. Each topic is covered in great depth, and the attention to detail in the book was beyond my expectations. Although it’s not a beginner’s book, any developer with a reasonable amount of SQL experience should find it to be a valuable reference and would be hard-pressed not to learn something new. ➤ Mike Naberezny Partner at Maintainable Software; Coauthor of Rails for PHP Developers This is an excellent book for the software engineer who knows basic SQL but finds herself needing to design SQL databases for projects that go a little beyond the basics. ➤ Liz Neely Senior Database Programmer

Karwin’s book is full of good and practical advice, and it was published at the right time. While many people are focusing on the new and seemingly fancy stuff, professionals now have the chance and the perfect book to sharpen their SQL knowledge. ➤ Maik Schmidt Author of Enterprise Recipes with Ruby and Rails and Enterprise Integration with Ruby Bill has captured the essence of a slew of traps that we’ve probably all dug for ourselves at one point or another when working with SQL — without even realizing we’re in trouble. Bill’s antipatterns range from “I can’t believe I did that (again!)” hindsight gotchas to tricky scenarios where the best solution may run counter to the SQL dogma you grew up with. A good read for SQL diehards, novices, and everyone in between. ➤ Danny Thorpe Microsoft Principal Engineer; Author of Delphi Component Design

SQL Antipatterns Avoiding the Pitfalls of Database Programming

Bill Karwin

The Pragmatic Bookshelf Dallas, Texas • Raleigh, North Carolina

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf, PragProg and the linking g device are trademarks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://pragprog.com. For international rights, please contact [email protected].

Copyright © 2010 Bill Karwin. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. ISBN-13: 978-1-934356-55-5 Encoded using the finest acid-free high-entropy binary digits. Book version: P4.0—August 2014

Contents 1.

Introduction . . . Who This Book Is For What’s in This Book What’s Not in This Book Conventions Example Database Acknowledgments

.

.

.

.

.

.

.

.

.

.

1 2 3 5 6 8 10

Part I — Logical Database Design Antipatterns 2.

Jaywalking . . . . . . . . . Objective: Store Multivalue Attributes Antipattern: Format Comma-Separated Lists How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Create an Intersection Table

.

.

.

.

13 14 14 17 18 18

3.

Naive Trees . . . . . . . . . Objective: Store and Query Hierarchies Antipattern: Always Depend on One’s Parent How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Use Alternative Tree Models

.

.

.

.

23 24 24 28 28 30

4.

ID Required . . . . . . . . . Objective: Establish Primary Key Conventions Antipattern: One Size Fits All How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Tailored to Fit

.

.

.

.

43 44 45 48 50 50

Contents

• viii

5.

Keyless Entry . . . . . . . Objective: Simplify Database Architecture Antipattern: Leave Out the Constraints How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Declare Constraints

.

.

.

.

.

53 54 54 57 57 58

6.

Entity-Attribute-Value . . . . . Objective: Support Variable Attributes Antipattern: Use a Generic Attribute Table How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Model the Subtypes

.

.

.

.

.

61 61 62 68 68 69

7.

Polymorphic Associations . . . . Objective: Reference Multiple Parents Antipattern: Use Dual-Purpose Foreign Key How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Simplify the Relationship

.

.

.

.

.

77 78 78 81 83 83

8.

Multicolumn Attributes . . . . Objective: Store Multivalue Attributes Antipattern: Create Multiple Columns How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Create Dependent Table

.

.

.

.

.

.

89 89 90 93 94 94

9.

Metadata Tribbles . . . . . Objective: Support Scalability Antipattern: Clone Tables or Columns How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Partition and Normalize

.

.

.

.

.

.

97 98 98 103 103 104

Part II — Physical Database Design Antipatterns 10. Rounding Errors . . . . . . . . . Objective: Use Fractional Numbers Instead of Integers Antipattern: Use FLOAT Data Type How to Recognize the Antipattern

.

.

111 112 112 116

Contents

Legitimate Uses of the Antipattern Solution: Use NUMERIC Data Type

• ix

116 116

11. 31 Flavors . . . . . . . . . . . Objective: Restrict a Column to Specific Values Antipattern: Specify Values in the Column Definition How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Specify Values in Data

.

.

119 119 120 123 124 124

12. Phantom Files . . . . . . . . Objective: Store Images or Other Bulky Media Antipattern: Assume You Must Use Files How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Use BLOB Data Types As Needed

.

.

.

.

127 128 128 131 132 133

13. Index Shotgun . . . . . . . Objective: Optimize Performance Antipattern: Using Indexes Without a Plan How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: MENTOR Your Indexes

.

.

.

.

135 136 136 140 141 141

14. Fear of the Unknown . . . . . . . . . Objective: Distinguish Missing Values Antipattern: Use Null as an Ordinary Value, or Vice Versa How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Use Null as a Unique Value

.

149 149 150 153 154 154

15. Ambiguous Groups . . . . . . . . Objective: Get Row with Greatest Value per Group Antipattern: Reference Nongrouped Columns How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Use Columns Unambiguously

.

.

.

159 160 160 162 163 164

16. Random Selection . . . . Objective: Fetch a Sample Row

.

.

.

169 169

.

Part III — Query Antipatterns

.

.

.

.

Contents

Antipattern: Sort Data Randomly How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: In No Particular Order… 17. Poor Man’s Search Engine . . . . Objective: Full-Text Search Antipattern: Pattern Matching Predicates How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Use the Right Tool for the Job

•x

170 171 172 172 .

.

.

.

.

177 178 178 179 180 180

18. Spaghetti Query . . . . . . . . Objective: Decrease SQL Queries Antipattern: Solve a Complex Problem in One Step How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Divide and Conquer

.

.

.

191 192 192 194 195 196

19. Implicit Columns . . . . . . . Objective: Reduce Typing Antipattern: a Shortcut That Gets You Lost How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Name Columns Explicitly

.

.

.

201 202 202 204 204 205

.

Part IV — Application Development Antipatterns 20. Readable Passwords . . . . . . Objective: Recover or Reset Passwords Antipattern: Store Password in Plain Text How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Store a Salted Hash of the Password

.

.

.

.

211 211 212 214 214 215

21. SQL Injection . . . . . . . . Objective: Write Dynamic SQL Queries Antipattern: Execute Unverified Input As Code How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Trust No One

.

.

.

.

223 224 224 231 231 231

Contents

22. Pseudokey Neat-Freak . . . Objective: Tidy Up the Data Antipattern: Filling in the Corners How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Get Over It

.

.

• xi

.

.

.

.

.

237 238 238 240 241 241

.

.

.

.

.

245 246 246 248 249 249

24. Diplomatic Immunity . . . . . . . Objective: Employ Best Practices Antipattern: Make SQL a Second-Class Citizen How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Establish a Big-Tent Culture of Quality

.

.

.

253 254 254 255 256 256

25. Magic Beans . . . . . . . . Objective: Simplify Models in MVC Antipattern: The Model Is an Active Record How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: The Model Has an Active Record

.

.

.

.

265 266 267 272 273 273

23. See No Evil . . . . . . . . Objective: Write Less Code Antipattern: Making Bricks Without Straw How to Recognize the Antipattern Legitimate Uses of the Antipattern Solution: Recover from Errors Gracefully

Part V — Appendixes A1. Rules of Normalization . . What Does Relational Mean? Myths About Normalization What Is Normalization? Common Sense

.

.

.

.

.

.

.

.

283 283 285 286 296

A2. Bibliography Index

.

.

.

.

.

.

.

.

.

.

.

.

.

.

297

.

.

.

.

.

.

.

.

.

.

.

.

299

An expert is a person who has made all the mistakes that can be made in a very narrow field.

➤ Niels Bohr

CHAPTER 1

Introduction I turned down my first SQL job. Shortly after I finished my college degree in computer and information science at the University of California, I was approached by a manager who worked at the university and knew me through campus activities. He had his own software startup company on the side that was developing a database management system portable between various UNIX platforms using shell scripts and related tools such as awk (at this time, modern dynamic languages like Ruby, Python, PHP, and even Perl weren’t popular yet). The manager approached me because he needed a programmer to write the code to recognize and execute a limited version of the SQL language. He said, “I don’t need to support the full language—that would be too much work. I need only one SQL statement: SELECT.” I hadn’t been taught SQL in school. Databases weren’t as ubiquitous as they are today, and open source brands like MySQL and PostgreSQL didn’t exist yet. But I had developed complete applications in shell, and I knew something about parsers, having done projects in classes like compiler design and computational linguistics. So, I thought about taking the job. How hard could it be to parse a single statement of a specialized language like SQL? I found a reference for SQL and noticed immediately that this was a different sort of language from those that support statements like if() and while(), variable assignments and expressions, and perhaps functions. To call SELECT only one statement in that language is like calling an engine only one part of an automobile. Both sentences are literally true, but they certainly belie the complexity and depth of their subjects. To support execution of that single SQL statement, I realized I would have to develop all the code for a fully functional relational database management system and query engine.

report erratum • discuss

Chapter 1. Introduction

•2

I declined this opportunity to code an SQL parser and RDBMS engine in shell script. The manager underrepresented the scope of his project, perhaps because he didn’t understand what an RDBMS does. My early experience with SQL seems to be a common one for software developers, even those who have a college degree in computer science. Most people are self-taught in SQL, learning it out of self-defense when they find themselves working on a project that requires it, instead of studying it explicitly as they would most programming languages. Regardless of whether the person is a hobbyist or a professional programmer or an accomplished researcher with a PhD, SQL seems to be a software skill that programmers learn without training. Once I learned something about SQL, I was surprised how different it is from procedural programming languages such as C, Pascal, and shell, or objectoriented languages like C++, Java, Ruby, or Python. SQL is a declarative programming language like LISP, Haskell, or XSLT. SQL uses sets as a fundamental data structure, while object-oriented languages use objects. Traditionally trained software developers are turned off by this so-called impedance mismatch, so many programmers are drawn to object-oriented libraries to avoid learning how to use SQL effectively. Since 1992, I’ve worked with SQL a lot. I’ve used it when developing applications, I’ve developed libraries for SQL programming in Perl and PHP, and I’ve provided technical support and developed training and documentation for the InterBase RDBMS product. I’ve answered thousands of questions on Internet mailing lists and newsgroups. I see a lot of repeat business—frequently asked questions that show that software developers make the same mistakes over and over again.

Who This Book Is For I’m writing SQL Antipatterns for software developers who need to use SQL so I can help you use the language more effectively. It doesn’t matter whether you’re a beginner or a seasoned professional. I’ve talked to people of all levels of experience who would benefit from the subjects in this book. You may have read a reference on SQL syntax. Now you know all the clauses of a SELECT statement, and you can get some work done. Gradually, you may increase your SQL skills by inspecting other applications and reading articles. But how can you tell good examples from bad examples? How can you be sure you’re learning best practices, instead of yet another way to paint yourself into a corner?

report erratum • discuss

What’s in This Book

•3

You may find some topics in SQL Antipatterns that are well-known to you. You’ll see new ways of looking at the problems, even if you’re already aware of the solutions. It’s good to confirm and reinforce your good practices by reviewing widespread programmer misconceptions. Other topics may be new to you. I hope you can improve your SQL programming habits by reading them. If you are a trained database administrator, you may already know the best ways to avoid the SQL pitfalls described in this book. This book can help you by introducing you to the perspective of software developers. It’s not uncommon for the relationship between developers and DBAs to be contentious, but mutual respect and teamwork can help us to work together more effectively. Use SQL Antipatterns to help explain good practices to the software developers you work with and the consequences of straying from that path.

What’s in This Book What is an antipattern? An antipattern is a technique that is intended to solve a problem but that often leads to other problems. An antipattern is practiced widely in different ways, but with a thread of commonality. People may come up with an idea that fits an antipattern independently or with help from a colleague, a book, or an article. Many antipatterns of object-oriented software design and project management are documented at the Portland Pattern Repository,1 as well as in the 1998 book AntiPatterns [BMMM98] by William J. Brown et al. SQL Antipatterns describes the most frequently made missteps I’ve seen people naively make while using SQL as I’ve talked to them in technical support and training sessions, worked alongside them developing software, and answered their questions on Internet forums. Many of these blunders I’ve made myself; there’s no better teacher than spending many hours late at night making up for one’s own errors.

Parts of This Book This book has four parts for the following categories of antipatterns: Logical Database Design Antipatterns Before you start coding, you should decide what information you need to keep in your database and the best way to organize and interconnect your data. This includes planning database tables, columns, and relationships.

1.

Portland Pattern Repository: http://c2.com/cgi-bin/wiki?AntiPattern

report erratum • discuss

Chapter 1. Introduction

•4

Physical Database Design Antipatterns After you know what data you need to store, you implement the data management as efficiently as you can using the features of your RDBMS technology. This includes defining tables and indexes and choosing data types. You use SQL’s data definition language—statements such as CREATE TABLE. Query Antipatterns You need to add data to your database and then retrieve data. SQL queries are made with data manipulation language—statements such as SELECT, UPDATE, and DELETE. Application Development Antipatterns SQL is supposed to be used in the context of applications written in another language, such as C++, Java, PHP, Python, or Ruby. There are right ways and wrong ways to employ SQL in an application, and this part of the book describes some common blunders. Many of the antipattern chapters have humorous or evocative titles, such as Golden Hammer, Reinventing the Wheel, or Design by Committee. It’s traditional to give both positive design patterns and antipatterns names that serve as a metaphor or mnemonic. The appendix provides practical descriptions of some relational database theory. Many of the antipatterns this book covers are the result of misunderstanding database theory.

Anatomy of an Antipattern Each antipattern chapter contains the following subheadings: Objective This is the task that you may be trying to solve. Antipatterns are used with an intention to provide that solution but end up causing more problems than they solve. The Antipattern This section describes the nature of the common solution and illustrates the unforeseen consequences that make it an anti-pattern. How to Recognize the Antipattern There may be certain clues that help you identify when an antipattern is being used in your project. Certain types of barriers you encounter, or quotes you may hear yourself or others saying, can tip you off to the presence of an antipattern.

report erratum • discuss

What’s Not in This Book

•5

Legitimate Uses of the Antipattern Rules usually have exceptions. There may be circumstances in which an approach normally considered an antipattern is nevertheless appropriate, or at least the lesser of all evils. Solution This section describes the preferred solutions, which solve the original objective without running into the problems caused by the antipattern.

What’s Not in This Book I’m not going to give lessons on SQL syntax or terminology. There are plenty of books and Internet references for the basics. I assume you have already learned enough SQL syntax to use the language and get some work done. Performance, scalability, and optimization are important for many people who develop database-driven applications, especially on the Web. There are books specifically about performance issues related to database programming. I recommend SQL Performance Tuning [GP03] and High Performance MySQL, Second Edition [SZTZ08]. Some of the topics in SQL Antipatterns are relevant to performance, but it’s not the main focus of the book. I try to present issues that apply to all database brands and also solutions that should work with all brands. The SQL language is specified as an ANSI and ISO standard. All brands of databases support these standards, so I describe vendor-neutral use of SQL whenever possible, and I try to be clear when describing vendor extensions to SQL. Data access frameworks and object-relational mapping libraries are helpful tools, but these aren’t the focus of this book. I’ve written most code examples in PHP, in the plainest way I can. The examples are simple enough that they’re equally relevant to most programming languages. Database administration and operation tasks such as server sizing, installation and configuration, monitoring, backups, log analysis, and security are important and deserve a book of their own, but I’m targeting this book to developers using the SQL language more than database administrators. This book is about SQL and relational databases, not alternative technology such as object-oriented databases, key/value stores, column-oriented databases, document-oriented databases, hierarchical databases, network databases, map/reduce frameworks, or semantic data stores. Comparing the strengths and weaknesses and appropriate uses of these alternative solutions for data management would be interesting but is a matter for other books.

report erratum • discuss

Chapter 1. Introduction

•6

Conventions The following sections describe some conventions I use in this book.

Typography SQL keywords are formatted in all-capitals and in a monospaced font to make them stand out from the text, as in SELECT. SQL tables, also in a monospaced font, are spelled with a capital for the initial letter of each word in the table name, as in Accounts or BugsProducts. SQL columns, also in a monospaced font, are spelled in lowercase, and words are separated by underscores, as in account_name. Literal strings are formatted in italics, as in [email protected].

Terminology SQL is correctly pronounced “ess-cue-ell,” not “see-quell.” Though I have no objection to the latter being used colloquially, I try to use the former, so in this book you will read phrases like “an SQL query,” not “a SQL query.” In the context of database-related usage, the word index refers to an ordered collection of information. The preferred plural of this word is indexes. In other contexts, an index may mean an indicator and is typically pluralized as indices. Both are correct according to most dictionaries, and this causes some confusion among writers. In this book, I spell the plural as indexes. In SQL, the terms query and statement are somewhat interchangeable, being any complete SQL command that you can execute. For the sake of clarity, I use query to refer to SELECT statements and statement for all others, including INSERT, UPDATE, and DELETE statements, as well as data definition statements.

Entity-Relationship Diagrams The most common way to diagram relational databases is with entity-relationship diagrams. Tables are shown as boxes, and relationships are shown as lines connecting the boxes, with symbols at either end of the lines describing the cardinality of the relationship. For examples, see Figure 1, Examples of entity-relationship diagrams, on page 7.

report erratum • discuss

Conventions

•7

Many-to-One Each account may log many bugs

Bugs

Accounts One-to-Many

Each bug may have many comments

Bugs

Comments One-to-One Each product has one installer

Products

Installers Many-to-Many

Each product may have many bugs; a bug may pertain to many products

Bugs

Products

Many-to-Many Same as above, with intersection table

Bugs

BugsProducts

Products

Figure 1—Examples of entity-relationship diagrams

report erratum • discuss

Chapter 1. Introduction

•8

Example Database I illustrate most of the topics in SQL Antipatterns using a database for a hypothetical bug-tracking application. The entity-relationship diagram for this database is shown in Figure 2, Diagram for example bug database, on page 10. Notice the three connections between the Bugs table and the Accounts table, representing three separate foreign keys. The following data definition language shows how I define the tables. In some cases, choices are made for the sake of examples later in the book, so they might not always be the choices one would make in a real-world application. I try to use only standard SQL so the example is applicable to any brand of database, but some MySQL data types also appear, such as SERIAL and BIGINT. Introduction/setup.sql CREATE TABLE Accounts ( account_id SERIAL PRIMARY KEY, account_name VARCHAR(20), first_name VARCHAR(20), last_name VARCHAR(20), email VARCHAR(100), password_hash CHAR(64), portrait_image BLOB, hourly_rate NUMERIC(9,2) ); CREATE TABLE BugStatus ( status VARCHAR(20) PRIMARY KEY ); CREATE TABLE Bugs ( bug_id SERIAL PRIMARY KEY, date_reported DATE NOT NULL, summary VARCHAR(80), description VARCHAR(1000), resolution VARCHAR(1000), reported_by BIGINT UNSIGNED NOT NULL, assigned_to BIGINT UNSIGNED, verified_by BIGINT UNSIGNED, status VARCHAR(20) NOT NULL DEFAULT 'NEW', priority VARCHAR(20), hours NUMERIC(9,2), FOREIGN KEY (reported_by) REFERENCES Accounts(account_id), FOREIGN KEY (assigned_to) REFERENCES Accounts(account_id), FOREIGN KEY (verified_by) REFERENCES Accounts(account_id), FOREIGN KEY (status) REFERENCES BugStatus(status) );

report erratum • discuss

Example Database

•9

CREATE TABLE Comments ( comment_id SERIAL PRIMARY KEY, bug_id BIGINT UNSIGNED NOT NULL, author BIGINT UNSIGNED NOT NULL, comment_date DATETIME NOT NULL, comment TEXT NOT NULL, FOREIGN KEY (bug_id) REFERENCES Bugs(bug_id), FOREIGN KEY (author) REFERENCES Accounts(account_id) ); CREATE TABLE Screenshots ( bug_id BIGINT UNSIGNED NOT NULL, image_id BIGINT UNSIGNED NOT NULL, screenshot_image BLOB, caption VARCHAR(100), PRIMARY KEY (bug_id, image_id), FOREIGN KEY (bug_id) REFERENCES Bugs(bug_id) ); CREATE TABLE Tags ( bug_id BIGINT UNSIGNED NOT NULL, tag VARCHAR(20) NOT NULL, PRIMARY KEY (bug_id, tag), FOREIGN KEY (bug_id) REFERENCES Bugs(bug_id) ); CREATE TABLE Products ( product_id SERIAL PRIMARY KEY, product_name VARCHAR(50) ); CREATE TABLE BugsProducts( bug_id BIGINT UNSIGNED NOT NULL, product_id BIGINT UNSIGNED NOT NULL, PRIMARY KEY (bug_id, product_id), FOREIGN KEY (bug_id) REFERENCES Bugs(bug_id), FOREIGN KEY (product_id) REFERENCES Products(product_id) );

report erratum • discuss

Chapter 1. Introduction

• 10

Figure 2—Diagram for example bug database In some chapters, especially those in Logical Database Design Antipatterns, I show different database definitions, either to exhibit the antipattern or to show an alternative solution that avoids the antipattern.

Acknowledgments First and foremost, I owe my gratitude to my wife Jan. I could not have written this book without the inspiration, love, and support you give me, not to mention the occasional kick in the pants. I also want to express thanks to my reviewers for giving me a lot of their time. Their suggestions improved the book greatly. Marcus Adams, Jeff Bean, Frederic Daoud, Darby Felton, Arjen Lentz, Andy Lester, Chris Levesque, Mike Naberezny, Liz Nealy, Daev Roehr, Marco Romanini, Maik Schmidt, Gale Straney, and Danny Thorpe. Thanks to my editor Jacquelyn Carter and the publishers of Pragmatic Bookshelf, who believed in the mission of this book.

report erratum • discuss

Part I

Logical Database Design Antipatterns

A Netscape engineer who shan’t be named once passed a pointer to JavaScript, stored it as a string, and later passed it back to C, killing 30.

➤ Blake Ross

CHAPTER 2

Jaywalking You’re developing a feature in the bug-tracking application to designate a user as the primary contact for a product. Your original design allowed only one user to be the contact for each product. However, it was no surprise when you were requested to support assigning multiple users as contacts for a given product. At the time, it seemed simple to change the database to store a list of user account identifiers separated by commas, instead of the single identifier it used before. Soon your boss approaches you with a problem. “The engineering department has been adding associate staff to their projects. They tell me they can add five people only. If they try to add more, they get an error. What’s going on?” You nod, “Yeah, you can only list so many people on a project,” as though this is completely ordinary. Sensing that your boss needs a more precise explanation, “Well, five to ten— maybe a few more. It depends on how old each person’s account is.” Now your boss raises his eyebrows. You continue, “I store the account IDs for a project in a comma-separated list. But the list of IDs has to fit in a string with a maximum length. If the account IDs are short, I can fit more in the list. So, people who created the earlier accounts have an ID of 99 or less, and those are shorter.” Your boss frowns. You have a feeling you’re going to be staying late. Programmers commonly use comma-separated lists to avoid creating an intersection table for a many-to-many relationship. I call this antipattern Jaywalking, because jaywalking is also an act of avoiding an intersection.

report erratum • discuss

Chapter 2. Jaywalking

• 14

Objective: Store Multivalue Attributes When a column in a table has a single value, the design is straightforward: you can choose an SQL data type to represent a single instance of that value, for example an integer, date, or string. But how do you store a collection of related values in a column? In the example bug-tracking database, we might associate a product with a contact using an integer column in the Products table. Each account may have many products, and each product references one contact, so we have a manyto-one relationship between products and accounts. Jaywalking/obj/create.sql CREATE TABLE Products ( product_id SERIAL PRIMARY KEY, product_name VARCHAR(1000), account_id BIGINT UNSIGNED, -- . . . FOREIGN KEY (account_id) REFERENCES Accounts(account_id) ); INSERT INTO Products (product_id, product_name, account_id) VALUES (DEFAULT, 'Visual TurboBuilder', 12);

As your project matures, you realize that a product might have multiple contacts. In addition to the many-to-one relationship, we also need to support a one-to-many relationship from products to accounts. One row in the Products table must be able to have more than one contact.

Antipattern: Format Comma-Separated Lists To minimize changes to the database structure, you decide to redefine the account_id column as a VARCHAR so you can list multiple account IDs in that column, separated by commas. Jaywalking/anti/create.sql CREATE TABLE Products ( product_id SERIAL PRIMARY KEY, product_name VARCHAR(1000), account_id VARCHAR(100), -- comma-separated list -- . . . ); INSERT INTO Products (product_id, product_name, account_id) VALUES (DEFAULT, 'Visual TurboBuilder', '12,34');

report erratum • discuss

Antipattern: Format Comma-Separated Lists

• 15

This seems like a win, because you’ve created no additional tables or columns; you’ve changed the data type of only one column. However, let’s look at the performance and data integrity problems this table design suffers from.

Querying Products for a Specific Account Queries are difficult if all the foreign keys are combined into a single field. You can no longer use equality; instead, you have to use a test against some kind of pattern. For example, MySQL lets you write something like the following to find all the products for account 12: Jaywalking/anti/regexp.sql SELECT * FROM Products WHERE account_id REGEXP '[[::]]';

Pattern-matching expressions may return false matches and can’t benefit from indexes. Since pattern-matching syntax is different in each database brand, your SQL code isn’t vendor-neutral.

Querying Accounts for a Given Product Likewise, it’s awkward and costly to join a comma-separated list to matching rows in the referenced table. Jaywalking/anti/regexp.sql SELECT * FROM Products AS p JOIN Accounts AS a ON p.account_id REGEXP '[[::]]' WHERE p.product_id = 123;

Joining two tables using an expression like this one spoils any chance of using indexes. The query must scan through both tables, generate a cross product, and evaluate the regular expression for every combination of rows.

Making Aggregate Queries Aggregate queries use functions like COUNT(), SUM(), and AVG(). However, these functions are designed to be used over groups of rows, not comma-separated lists. You have to resort to tricks like the following: Jaywalking/anti/count.sql SELECT product_id, LENGTH(account_id) - LENGTH(REPLACE(account_id, ',', '')) + 1 AS contacts_per_product FROM Products;

Tricks like this can be clever but never clear. These kinds of solutions are time-consuming to develop and hard to debug. Some aggregate queries can’t be accomplished with tricks at all.

report erratum • discuss

Chapter 2. Jaywalking

• 16

Updating Accounts for a Specific Product You can add a new ID to the end of the list with string concatenation, but this might not leave the list in sorted order. Jaywalking/anti/update.sql UPDATE Products SET account_id = account_id || ',' || 56 WHERE product_id = 123;

To remove an item from the list, you have to run two SQL queries: one to fetch the old list and a second to save the updated list. Jaywalking/anti/remove.php