Tài liệu SQL Antipatterns- P1 docx

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.... SQL AntipatternsAvoiding the Pitfalls of Database Programming Bill Karwin The Pragmatic Bookshelf Raleigh,

Trang 1

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Trang 2

What Readers Are Saying About SQL Antipatterns

I am a strong advocate of best practices I prefer to learn from otherpeople’s mistakes This book is a comprehensive collection of thoseother people’s mistakes and, quite surprisingly, some of my own Iwish 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 patterns and solutions described here I immediately applied tech-niques from this book and improved my applications Fantastic work!

on requirements, expectations, measurements, and reality

Darby Felton

Cofounder, DevBots Software Development

I really like how Bill has approached this book; it shows his uniquestyle and sense of humor Those things are really important whendiscussing potentially dry topics Bill has succeeded in making theteachings accessible for developers in a good descriptive form, aswell as being easy to reference later In short, this is an excellent newresource for your pragmatic bookshelf!

Arjen Lentz

Executive Director of Open Query (http://openquery.com);

Trang 3

This book is obviously the product of many years of practical rience 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 reasonableamount of SQL experience should find it to be a valuable referenceand would be hard-pressed not to learn something new.

Liz Neely

Senior Database Programmer

Karwin’s book is full of good and practical advice, and it was lished at the right time While many people are focusing on the newand seemingly fancy stuff, professionals now have the chance and theperfect book to sharpen their SQL knowledge

“I can’t believe I did that (again!)” hindsight gotchas to tricky ios where the best solution may run counter to the SQL dogma yougrew up with A good read for SQL diehards, novices, and everyone inbetween

Trang 5

SQL Antipatterns

Avoiding the Pitfalls of Database Programming

Bill Karwin

The Pragmatic Bookshelf

Raleigh, North Carolina Dallas, Texas

Trang 6

Many of the designations used by manufacturers and sellers to distinguish their ucts 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

prod-Pragmatic Programmer, prod-Pragmatic Programming, prod-Pragmatic Bookshelf 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://www.pragprog.com

No part of this publication may be reproduced, stored in a retrieval system, or ted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher.

transmit-Printed in the United States of America.

ISBN-10: 1-934356-55-7 ISBN-13: 978-1-934356-55-5 Printed on acid-free paper.

P1.0 printing, May 2010

Trang 7

1.1 Who This Book Is For 14

1.2 What’s in This Book 15

1.3 What’s Not in This Book 17

1.4 Conventions 18

1.5 Example Database 19

1.6 Acknowledgments 22

I Logical Database Design Antipatterns 24 2 Jaywalking 25 2.1 Objective: Store Multivalue Attributes 26

2.2 Antipattern: Format Comma-Separated Lists 26

2.3 How to Recognize the Antipattern 29

2.4 Legitimate Uses of the Antipattern 30

2.5 Solution: Create an Intersection Table 30

3 Naive Trees 34 3.1 Objective: Store and Query Hierarchies 35

3.2 Antipattern: Always Depend on One’s Parent 35

3.5 Solution: Use Alternative Tree Models 41

4 ID Required 54 4.1 Objective: Establish Primary Key Conventions 55

4.2 Antipattern: One Size Fits All 57

4.5 Solution: Tailored to Fit 62

Trang 8

CONTENTS 8

5.1 Objective: Simplify Database Architecture 66

5.2 Antipattern: Leave Out the Constraints 66

5.5 Solution: Declare Constraints 70

6 Entity-Attribute-Value 73 6.1 Objective: Support Variable Attributes 73

6.2 Antipattern: Use a Generic Attribute Table 74

6.5 Solution: Model the Subtypes 82

7 Polymorphic Associations 89 7.1 Objective: Reference Multiple Parents 90

7.2 Antipattern: Use Dual-Purpose Foreign Key 91

7.5 Solution: Simplify the Relationship 96

8 Multicolumn Attributes 102 8.1 Objective: Store Multivalue Attributes 102

8.2 Antipattern: Create Multiple Columns 103

8.5 Solution: Create Dependent Table 108

9 Metadata Tribbles 110 9.1 Objective: Support Scalability 111

9.2 Antipattern: Clone Tables or Columns 111

9.5 Solution: Partition and Normalize 118

Trang 9

CONTENTS 9

II Physical Database Design Antipatterns 122

10.1 Objective: Use Fractional Numbers Instead of Integers 124

10.2 Antipattern: Use FLOAT Data Type 124

10.5 Solution: Use NUMERIC Data Type 128

11 31 Flavors 131 11.1 Objective: Restrict a Column to Specific Values 131

11.2 Antipattern: Specify Values in the Column Definition 132 11.3 How to Recognize the Antipattern 135

11.5 Solution: Specify Values in Data 136

12 Phantom Files 139 12.1 Objective: Store Images or Other Bulky Media 140

12.2 Antipattern: Assume You Must Use Files 140

12.5 Solution: Use BLOB Data Types As Needed 145

13 Index Shotgun 148 13.1 Objective: Optimize Performance 149

13.2 Antipattern: Using Indexes Without a Plan 149

13.5 Solution: MENTOR Your Indexes 154

III Query Antipatterns 161 14 Fear of the Unknown 162 14.1 Objective: Distinguish Missing Values 163

14.2 Antipattern: Use Null as an Ordinary Value, or Vice Versa163 14.3 How to Recognize the Antipattern 166

14.5 Solution: Use Null as a Unique Value 168

Report erratum

Trang 10

CONTENTS 10

15.1 Objective: Get Row with Greatest Value per Group 174

15.2 Antipattern: Reference Nongrouped Columns 174

15.5 Solution: Use Columns Unambiguously 179

16 Random Selection 183 16.1 Objective: Fetch a Sample Row 184

16.2 Antipattern: Sort Data Randomly 184

16.5 Solution: In No Particular Order 186

17 Poor Man’s Search Engine 190 17.1 Objective: Full-Text Search 191

17.2 Antipattern: Pattern Matching Predicates 191

17.5 Solution: Use the Right Tool for the Job 193

18 Spaghetti Query 204 18.1 Objective: Decrease SQL Queries 205

18.2 Antipattern: Solve a Complex Problem in One Step 205

18.5 Solution: Divide and Conquer 209

19 Implicit Columns 214 19.1 Objective: Reduce Typing 215

19.2 Antipattern: a Shortcut That Gets You Lost 215

19.5 Solution: Name Columns Explicitly 219

Trang 11

CONTENTS 11

20.1 Objective: Recover or Reset Passwords 222

20.2 Antipattern: Store Password in Plain Text 223

20.5 Solution: Store a Salted Hash of the Password 227

21 SQL Injection 234 21.1 Objective: Write Dynamic SQL Queries 235

21.2 Antipattern: Execute Unverified Input As Code 235

21.5 Solution: Trust No One 243

22 Pseudokey Neat-Freak 250 22.1 Objective: Tidy Up the Data 251

22.2 Antipattern: Filling in the Corners 251

22.5 Solution: Get Over It 254

23 See No Evil 259 23.1 Objective: Write Less Code 260

23.2 Antipattern: Making Bricks Without Straw 260

23.5 Solution: Recover from Errors Gracefully 264

24 Diplomatic Immunity 266 24.1 Objective: Employ Best Practices 267

24.2 Antipattern: Make SQL a Second-Class Citizen 267

24.5 Solution: Establish a Big-Tent Culture of Quality 269

25 Magic Beans 278 25.1 Objective: Simplify Models in MVC 279

25.2 Antipattern: The Model Is an Active Record 280

25.5 Solution: The Model Has an Active Record 287

Report erratum

Trang 12

CONTENTS 12

A.1 What Does Relational Mean? 294

A.2 Myths About Normalization 296

A.3 What Is Normalization? 298

A.4 Common Sense 308

Trang 13

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 informationscience at the University of California, I was approached by a managerwho worked at the university and knew me through campus activi-ties He had his own software startup company on the side that wasdeveloping a database management system portable between variousUNIXplatforms using shell scripts and related tools such asawk(at thistime, modern dynamic languages like Ruby, Python, PHP, and even Perlweren’t popular yet) The manager approached me because he needed aprogrammer 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 toomuch 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 PostgreSQLdidn’t exist yet But I had developed complete applications in shell,and I knew something about parsers, having done projects in classeslike compiler design and computational linguistics So, I thought abouttaking the job How hard could it be to parse a single statement of aspecialized language like SQL?

I found a reference for SQL and noticed immediately that this was adifferent sort of language from those that support statements like if( )and while( ), variable assignments and expressions, and perhaps func-tions To callSELECTonly one statement in that language is like calling

an engine only one part of an automobile Both sentences are literallytrue, but they certainly belie the complexity and depth of their subjects

To support execution of that single SQL statement, I realized I wouldPlease purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Trang 14

WHOTHISBOOKISFOR 14

have to develop all the code for a fully functional relational databasemanagement system and query engine

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 softwaredevelopers, even those who have a college degree in computer science

Most people are self-taught in SQL, learning it out of self-defense whenthey 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 grammer or an accomplished researcher with a PhD, SQL seems to be

pro-a softwpro-are skill thpro-at progrpro-ammers lepro-arn without trpro-aining

Once I learned something about SQL, I was surprised how different

it is from procedural programming languages such as C, Pascal, andshell, or object-oriented 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

program-mers are drawn to object-oriented libraries to avoid learning how touse SQL effectively

Since 1992, I’ve worked with SQL a lot I’ve used it when developingapplications, I’ve provided technical support and developed trainingand documentation for the InterBase RDBMS product, and I’ve devel-oped libraries for SQL programming in Perl and PHP I’ve answeredthousands of questions on Internet mailing lists and newsgroups I see

a lot of repeat business—frequently asked questions that show thatsoftware developers make the same mistakes over and over again

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’tmatter 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

Trang 15

WHAT’S INTHISBOOK 15

You may have read a reference on SQL syntax Now you know all theclauses of aSELECTstatement, and you can get some work done Gradu-ally, you may increase your SQL skills by inspecting other applicationsand reading articles But how can you tell good examples from badexamples? How can you be sure you’re learning best practices, instead

of yet another way to paint yourself into a corner?

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’realready aware of the solutions It’s good to confirm and reinforce yourgood practices by reviewing widespread programmer misconceptions

Other topics may be new to you I hope you can improve your SQLprogramming habits by reading them

If you are a trained database administrator, you may already knowthe best ways to avoid the SQL pitfalls described in this book Thisbook can help you by introducing you to the perspective of softwaredevelopers It’s not uncommon for the relationship between developersand 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 andthe consequences of straying from that path

What is an antipattern? An antipattern is a technique that is intended

to solve a problem but that often leads to other problems An tern is practiced widely in different ways, but with a thread of common-ality People may come up with an idea that fits an antipattern inde-pendently or with help from a colleague, a book, or an article Manyantipatterns of object-oriented software design and project manage-ment are documented at the Portland Pattern Repository,1 as well as

antipat-in the 1998 book AntiPatterns [BMMM98] by William J Brown et al

SQL Antipatternsdescribes the most frequently made missteps I’ve seenpeople naively make while using SQL as I’ve talked to them in techni-cal support and training sessions, worked alongside them developingsoftware, and answered their questions on Internet forums Many ofthese blunders I’ve made myself; there’s no better teacher than spend-ing many hours late at night making up for one’s own errors

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

Report erratum

Trang 16

WHAT’S INTHISBOOK 16

Parts of This Book

This book has four parts for the following categories of antipatterns:

Logical Database Design AntipatternsBefore you start coding, you should decide what information youneed to keep in your database and the best way to organize andinterconnect your data This includes planning your databasetables, columns, and relationships

Physical Database Design AntipatternsAfter you know what data you need to store, you implement thedata management as efficiently as you can using the features ofyour RDBMS technology This includes defining tables and in-

dexes and choosing data types You use SQL’s data definition guage—statements such asCREATE TABLE

lan-Query AntipatternsYou need to add data to your database and then retrieve data SQL

queries are made with data manipulation language—statements

such asSELECT,UPDATE, andDELETE

Application Development AntipatternsSQL 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 tion, and this part of the book describes some common blunders

applica-Many of the antipattern chapters have humorous or evocative titles,

such as Golden Hammer, Reinventing the Wheel, or Design by tee It’s traditional to give both positive design patterns and antipat-terns names that serve as a metaphor or mnemonic

Commit-The appendix provides practical descriptions of some relational base theory Many of the antipatterns this book covers are the result ofmisunderstanding database theory

data-Anatomy of an Antipattern

Each antipattern chapter contains the following subheadings:

ObjectiveThis is the task that you may be trying to solve Antipatterns areused with an intention to provide that solution but end up causingmore problems than they solve

Trang 17

WHAT’SNOT INTHISBOOK 17

The AntipatternThis section describes the nature of the common solution andillustrates the unforeseen consequences that make it an anti-pattern

How to Recognize the AntipatternThere may be certain clues that help you identify when an antipat-tern is being used in your project Certain types of barriers youencounter, or quotes you may hear yourself or others saying, cantip you off to the presence of an antipattern

Legitimate Uses of the AntipatternRules usually have exceptions There may be circumstances inwhich an approach normally considered an antipattern is never-theless appropriate, or at least the lesser of all evils

SolutionThis section describes the preferred solutions, which solve theoriginal objective without running into the problems caused bythe antipattern

I’m not going to give lessons on SQL syntax or terminology There areplenty of books and Internet references for the basics I assume youhave already learned enough SQL syntax to use the language and getsome work done

Performance, scalability, and optimization are important for many ple who develop database-driven applications, especially on the Web

peo-There are books specifically about performance issues related to

data-base programming I recommend SQL Performance Tuning [GP03] and

High Performance MySQL, Second Edition[SZT+08] 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 tions that should work with all brands The SQL language is specified

solu-as an ANSI and ISO standard All brands of databsolu-ases support thesestandards, 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 arehelpful tools, but these aren’t the focus of this book I’ve written most

Report erratum

Trang 18

CONVENTIONS 18

code examples in PHP, in the plainest way I can The examples aresimple enough that they’re equally relevant to most programming lan-guages

Database administration and operation tasks such as server sizing,installation and configuration, monitoring, backups, log analysis, andsecurity are important and deserve a book of their own, but I’m target-ing this book to developers using the SQL language more than databaseadministrators

This book is about SQL and relational databases, not alternative nology such as object-oriented databases, key/value stores, column-oriented databases, document-oriented databases, hierarchical data-bases, network databases, map/reduce frameworks, or semantic datastores Comparing the strengths and weaknesses and appropriate uses

tech-of these alternative solutions for data management would be interestingbut is a matter for other books

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 inSELECT

SQL tables, also in a monospaced font, are spelled with a capital for theinitial letter of each word in the table name, as inAccountsorBugsProd-ucts SQL columns, also in a monospaced font, are spelled in lowercase,and words are separated by underscores, as inaccount_name

Literal strings are formatted in italics, as in bill@example.com.

In the context of database-related usage, the word index refers to an

ordered collection of information The preferred plural of this word is

Trang 19

EXAMPLEDATABASE 19

indexes In other contexts, an index may mean an indicator and is ically pluralized as indices Both are correct according to most dictio-

typ-naries, 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 toSELECTstatements and statement for all

others, includingINSERT,UPDATE, andDELETEstatements, as well as datadefinition statements

Entity-Relationship Diagrams

The most common way to diagram relational databases is with relationship diagrams Tables are shown as boxes, and relationshipsare shown as lines connecting the boxes, with symbols at either end ofthe lines describing the cardinality of the relationship For examples,see Figure1.1, on the following page

I illustrate most of the topics in SQL Antipatterns using a database for a

hypothetical bug-tracking application The entity-relationship diagramfor this database is shown in Figure 1.2, on page 21 Notice the threeconnections between theBugstable and theAccountstable, representingthree 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 thebook, so they might not always be the choices one would make in areal-world application I try to use only standard SQL so the example isapplicable to any brand of database, but some MySQL data types alsoappear, such asSERIAL andBIGINT

Download 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) );

Report erratum

Trang 20

EXAMPLEDATABASE 20

Accounts

Comments Bugs

Many-to-OneEach account may log many bugs

One-to-ManyEach bug may have many comments

Installers Products

One-to-OneEach product has one installer

Products Bugs

Many-to-ManyEach product may have many bugs;

a bug may pertain to many products

Products Bugs

Many-to-ManySame as above, with intersection table

BugsProductsBugs

Figure 1.1: Examples of entity-relationship diagrams

Trang 21

Tiêu đề	SQL Antipatterns: Avoiding the Pitfalls of Database Programming
Tác giả	Bill Karwin
Trường học	The Pragmatic Bookshelf
Chuyên ngành	Database Programming
Thể loại	Sách hướng dẫn
Thành phố	Raleigh, North Carolina

Định dạng
Số trang	50
Dung lượng	384,56 KB