The Art of SQL

by Stephane Faroult, Peter Robson

Overview

For all the buzz about trendy IT techniques, data processing is still at the core of our systems, especially now that enterprises all over the world are confronted with exploding volumes of data. Database performance has become a major headache, and most IT departments believe that developers should provide simple SQL code to solve immediate problems and let DBAs tune any "bad SQL" later.

In The Art of SQL, author and SQL expert Stephane Faroult argues that this "safe approach" only leads to disaster. His insightful book, named after Art of War by Sun Tzu, contends that writing quick inefficient code is sweeping the dirt under the rug. SQL code may run for 5 to 10 years, surviving several major releases of the database management system and on several generations of hardware. The code must be fast and sound from the start, and that requires a firm understanding of SQL and relational theory.

The Art of SQL offers best practices that teach experienced SQL users to focus on strategy rather than specifics. Faroult's approach takes a page from Sun Tzu's classic treatise by viewing database design as a military campaign. You need knowledge, skills, and talent. Talent can't be taught, but every strategist from Sun Tzu to modern-day generals believed that it can be nurtured through the experience of others. They passed on their experience acquired in the field through basic principles that served as guiding stars amid the sound and fury of battle. This is what Faroult does with SQL.

Like a successful battle plan, good architectural choices are based on contingencies. What if the volume of this or that table increases unexpectedly? What if, following a merger, the number of users doubles? What if you want to keep several years of data online? Faroult's way of looking at SQL performance may be unconventional and unique, but he's deadly serious about writing good SQL and using SQL well. The Art of SQL is not a cookbook, listing problems and giving recipes. The aim is to get you-and your manager-to raise good questions.

Product Details

ISBN-13:	9780596008949
Publisher:	O'Reilly Media, Incorporated
Publication date:	03/17/2006
Pages:	367
Sales rank:	308,120
Product dimensions:	7.00(w) x 9.19(h) x 0.86(d)

About the Author

Stephane Faroult first discovered relational databases and the SQL language back in 1983. He joined Oracle France in their early days (after a brief spell with IBM and a bout of teaching at the University of Ottawa) and soon developed an interest in performance and tuning topics. After leaving Oracle in 1988, he briefly tried to reform and did a bit of operational research, but after one year, he succumbed again to relational databases. He has been continuously performing database consultancy since then, and founded RoughSea Ltd in 1998.

Graduated in geology from Durham University(1968), then taught at Edinburgh University, obtaining an M.Phil in geology 1975. Worked in Greece as a geologist (1973,74), and then in University of Newcastle specialising in geological databases.
Joined the British Geological Survey 1980, and has steered the organisations' use of database ever since, as data architect and database administrator. Has worked with databases since 1977, relational databases since 1981, and Oracle since 1985. He has lectured widely in the UK on geological aspects of database and has specialised on aspects of the SQL system as well as data modelling from the corporate architecture down to the departmental level. He has presented at various Oracle database conferences both in the UK, Europe and North America. Currently a director on the board of the UK Oracle Users Group.

Table of Contents

Dedication; Preface; Why Another SQL Book?; Audience; Assumptions This Book Makes; Contents of This Book; Conventions Used in This Book; Using Code Examples; Comments and Questions; Safari® Enabled; Acknowledgments; Chapter 1: Laying Plans; 1.1 The Relational View of Data; 1.2 The Importance of Being Normal; 1.3 To Be or Not to Be, or to Be Null; 1.4 Qualifying Boolean Columns; 1.5 Understanding Subtypes; 1.6 Stating the Obvious; 1.7 The Dangers of Excess Flexibility; 1.8 The Difficulties of Historical Data; 1.9 Design and Performance; 1.10 Processing Flow; 1.11 Centralizing Your Data; 1.12 System Complexity; 1.13 The Completed Plans; Chapter 2: Waging War; 2.1 Query Identification; 2.2 Stable Database Connections; 2.3 Strategy Before Tactics; 2.4 Problem Definition Before Solution; 2.5 Stable Database Schema; 2.6 Operations Against Actual Data; 2.7 Set Processing in SQL; 2.8 Action-Packed SQL Statements; 2.9 Profitable Database Accesses; 2.10 Closeness to the DBMS Kernel; 2.11 Doing Only What Is Required; 2.12 SQL Statements Mirror Business Logic; 2.13 Program Logic into Queries; 2.14 Multiple Updates at Once; 2.15 Careful Use of User-Written Functions; 2.16 Succinct SQL; 2.17 Offensive Coding with SQL; 2.18 Discerning Use of Exceptions; Chapter 3: Tactical Dispositions; 3.1 The Identification of "Entry Points"; 3.2 Indexes and Content Lists; 3.3 Making Indexes Work; 3.4 Indexes with Functions and Conversions; 3.5 Indexes and Foreign Keys; 3.6 Multiple Indexing of the Same Columns; 3.7 System-Generated Keys; 3.8 Variability of Index Accesses; Chapter 4: Maneuvering; 4.1 The Nature of SQL; 4.2 Five Factors Governing the Art of SQL; 4.3 Filtering; Chapter 5: Terrain; 5.1 Structural Types; 5.2 The Conflicting Goals; 5.3 Considering Indexes as Data Repositories; 5.4 Forcing Row Ordering; 5.5 Automatically Grouping Data; 5.6 The Double-Edged Sword of Partitioning; 5.7 Partitioning and Data Distribution; 5.8 The Best Way to Partition Data; 5.9 Pre-Joining Tables; 5.10 Holy Simplicity; Chapter 6: The Nine Situations; 6.1 Small Result Set, Direct Specific Criteria; 6.2 Small Result Set, Indirect Criteria; 6.3 Small Intersection of Broad Criteria; 6.4 Small Intersection, Indirect Broad Criteria; 6.5 Large Result Set; 6.6 Self-Joins on One Table; 6.7 Result Set Obtained by Aggregation; 6.8 Simple or Range Searching on Dates; 6.9 Result Set Predicated on Absence of Data; Chapter 7: Variations in Tactics; 7.1 Tree Structures; 7.2 Representing Trees in an SQL Database; 7.3 Practical Implementation of Trees; 7.4 Walking a Tree with SQL; 7.5 Aggregating Values from Trees; Chapter 8: Weaknesses and Strengths; 8.1 Deceiving Criteria; 8.2 Abstract Layers; 8.3 Distributed Systems; 8.4 Dynamically Defined Search Criteria; Chapter 9: Multiple Fronts; 9.1 The Database Engine as a Service Provider; 9.2 Concurrent Data Changes; Chapter 10: Assembly of Forces; 10.1 Increasing Volumes; 10.2 Data Warehousing; Chapter 11: Stratagems; 11.1 Turning Data Around; 11.2 Querying with a Variable in List; 11.3 Aggregating by Range (Bands); 11.4 Superseding a General Case; 11.5 Selecting Rows That Match Several Items in a List; 11.6 Finding the Best Match; 11.7 Optimizer Directives; Chapter 12: Employment of Spies; 12.1 The Database Is Slow; 12.2 The Components of Server Load; 12.3 Defining Good Performance; 12.4 Thinking in Business Tasks; 12.5 Execution Plans; 12.6 Using Execution Plans Properly; 12.7 What Really Matters?; PHOTO CREDITS; About the Author;

Editorial Reviews

The Barnes & Noble Review
Database developers can’t fob off performance issues on DBAs anymore: They need to write optimized SQL code right from the start. With The Art of SQL, they will.

Stéphane Faroult consciously follows Sun Tzu’s classic The Art of War. Like great generals, Faroult says, SQL developers must plan well (design databases for performance); master tactics and maneuvering; handle the terrain (physical implementation); manage multiple fronts (concurrency); recognize classic situations and the corresponding SQL patterns; and make the most of spies (monitoring tools).

This book covers all that, and more. You’ll go beyond writing mere “statements,” understanding your real goals and anticipating the countermoves your environment might throw at you. (What if table volume suddenly increases, your user base doubles, you’re moved onto new hardware?) There’s plenty of code here, but what Faroult really does is teach better ways to think about SQL. Bill Camarda, from the June 2006 Read Only

bn.com