Secure CheckoutPersonal information is secured with SSL technology.
Free ShippingFree global shipping
No minimum order.
1.1 Purpose of the Book
1.3 Corrections, Comments, and Future Editions
Chapter 1: Names and Data Elements
1.2 Follow the ISO-11179 Standards Naming Conventions
1.3 Problems in Naming Data Elements
Chapter 2: Fonts, Punctuation, and Spacing
2.1 Typography and Code
2.2 Word Spacing
2.3 Follow Normal Punctuation Rules
2.4 Use Full Reserved Words
2.5 Avoid Proprietary Reserved Words if a Standard Keyword Is Available in Your SQL Product
2.6 Avoid Proprietary Statements if a Standard Statement Is Available
2.7 Rivers and Vertical Spacing
2.9 Use Line Spacing to Group Statements
Chapter 3: Data Declaration Language
3.1 Put the Default in the Right Place
3.2 The Default Value Should Be the Same Data Type as the Column
3.3 Do Not Use Proprietary Data Types
3.4 Place the PRIMARY KEY Declaration at the Start of the CREATE TABLE Statement
3.5 Order the Columns in a Logical Sequence and Cluster Them in Logical Groups
3.6 Indent Referential Constraints and Actions under the Data Type
3.7 Give Constraints Names in the Production Code
3.8 Put CHECK() Constraint Near what they Check
3.9 Put Multiple Column Constraints as Near to Both Columns as Possible
3.10 Put Table-Level CHECK() Constraints at the End of the Table Declaration
3.11 Use CREATE ASSERTION for Multi-table Constraints
3.12 Keep CHECK() Constraints Single Purposed
3.13 Every Table Must Have a Key to Be a Table
3.14 Do Not Split Attributes
3.15 Do Not Use Object-Oriented Design for an RDBMS
Chapter 4: Scales and Measurements
4.1 Measurement Theory
4.2 Types of Scales
4.3 Using Scales
4.4 Scale Conversion
4.5 Derived Units
4.6 Punctuation and Standard Units
4.7 General Guidelines for Using Scales in a Database
Chapter 5: Data Encoding Schemes
5.1 Bad Encoding Schemes
5.2 Encoding Scheme Types
5.3 General Guidelines for Designing Encoding Schemes
5.4 Multiple Character Sets
Chapter 6: Coding Choices
6.1 Pick Standard Constructions over Proprietary Constructions
6.2 Pick Compact Constructions over Longer Equivalents
6.3 Use Comments
6.4 Avoid Optimizer Hints
6.5 Avoid Triggers in Favor of DRI Actions
6.6 Use SQL Stored Procedures
6.7 Avoid User-Defined Functions and Extensions inside the Database
6.8 Avoid Excessive Secondary Indexes
6.9 Avoid Correlated Subqueries
6.10 Avoid UNIONS
6.11 Testing SQL
Chapter 7: How to Use Views
7.1 VIEW Naming Conventions Are the Same as Tables
7.2 VIEWs Provide Row- and Column-Level Security
7.3 VIEWs Ensure Efficient Access Paths
7.4 VIEWs Mask Complexity from the User
7.5 VIEWs Ensure Proper Data Derivation
7.6 VIEWs Rename Tables and/or Columns
7.7 VIEWs Enforce Complicated Integrity Constraints
7.8 Updatable VIEWs
7.9 Have a Reason for Each VIEW
7.10 Avoid VIEW Proliferation
7.11 Synchronize VIΕWs with Base Tables
7.12 Improper Use of VIEWs
7.13 Learn about Materialized VIEWs
Chapter 8: How to Write Stored Procedures
8.1 Most SQL 4GLs Are Not for Applications
8.2 Basic Software Engineering
8.3 Use Classic Structured Programming
8.4 Avoid Portability Problems
8.5 Scalar versus Structured Parameters
8.6 Avoid Dynamic SQL
Chapter 9: Heuristics
9.1 Put the Specification into a Clear Statement
9.2 Add the Words “Set of All . . ./” in Front of the Nouns
9.3 Remove Active Verbs from the Problem Statement
9.4 You Can Still Use Stubs
9.5 Do Not Worry about Displaying the Data
9.6 Your First Attempts Need Special Handling
9.7 Do Not Think with Boxes and Arrows
9.8 Draw Circles and Set Diagrams
9.9 Learn Your Dialect
9.10 Imagine That Your WHERE Clause Is “Super Ameba”
9.11 Use the Newsgroups and Internet
Chapter 10: Thinking in SQL
10.1 Bad Programming in SQL and Procedural Languages
10.2 Thinking of Columns as Fields
10.3 Thinking in Processes, Not Declarations
10.4 Thinking the Schema Should Look Like the Input Forms
ANSI and ISO Standards
U.S. Government Codes
Code Formatting and Naming Conventions
About the author
Are you an SQL programmer that, like many, came to SQL after learning and writing procedural or object-oriented code? Or have switched jobs to where a different brand of SQL is being used, or maybe even been told to learn SQL yourself?
If even one answer is yes, then you need this book. A "Manual of Style" for the SQL programmer, this book is a collection of heuristics and rules, tips, and tricks that will help you improve SQL programming style and proficiency, and for formatting and writing portable, readable, maintainable SQL code. Based on many years of experience consulting in SQL shops, and gathering questions and resolving his students’ SQL style issues, Joe Celko can help you become an even better SQL programmer.
- Help you write Standard SQL without an accent or a dialect that is used in another programming language or a specific flavor of SQL, code that can be maintained and used by other people.
- Enable you to give your group a coding standard for internal use, to enable programmers to use a consistent style.
- Give you the mental tools to approach a new problem with SQL as your tool, rather than another programming language — one that someone else might not know!
Managers seeking programming standards in their shops, team leaders seeking programming standards in their projects, SQL programmers attempting to set up programming standards in their own work, and newer SQL programmers who want to build good habits from the start.
- No. of pages:
- © Morgan Kaufmann 2005
- 17th April 2005
- Morgan Kaufmann
- Paperback ISBN:
- eBook ISBN:
“Joe Celko, maybe one of the most prominent representatives of the database community these days, has written some of the best books about SQL programming in general. This book, however, is different. “SQL Programming Style” doesn’t teach you how to become a better SQL developer with SQL puzzles and brainteasers. Rather, it shows you “how to work in logical and declarative terms”.” — SQL-Server-Performance.com, August 17, 2006
Joe Celko served 10 years on ANSI/ISO SQL Standards Committee and contributed to the SQL-89 and SQL-92 Standards.
Mr. Celko is author a series of books on SQL and RDBMS for Elsevier/MKP. He is an independent consultant based in Austin, Texas.
He has written over 1200 columns in the computer trade and academic press, mostly dealing with data and databases.
Independent Consultant, Austin, Texas
Elsevier.com visitor survey
We are always looking for ways to improve customer experience on Elsevier.com.
We would like to ask you for a moment of your time to fill in a short questionnaire, at the end of your visit.
If you decide to participate, a new browser tab will open so you can complete the survey after you have completed your visit to this website.
Thanks in advance for your time.