Skip to content

Joe Celko's SQL Programming Style

Spend $50 to get a free DVD!

ISBN-10: 0120887975

ISBN-13: 9780120887972

Edition: 2005

Authors: Joe Celko

List price: $45.95
Shipping box This item qualifies for FREE shipping.
Blue ribbon 30 day, 100% satisfaction guarantee!
Buy eBooks
what's this?
Rush Rewards U
Members Receive:
Carrot Coin icon
XP icon
You have reached 400 XP and carrot coins. That is the daily max!

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…    
Customers also bought

Book details

List price: $45.95
Copyright year: 2005
Publisher: Elsevier Science & Technology Books
Publication date: 5/19/2005
Binding: Paperback
Pages: 272
Size: 7.25" wide x 8.75" long x 0.50" tall
Weight: 1.100
Language: English

Rob Shimonski ( is an experienced entrepreneur and an active participant in the business community. Rob is a best-selling author and editor with over 15 years experience developing, producing and distributing print media in the form of books, magazines and periodicals. To date, Rob has successfully created over 100 books that are currently in circulation. Rob has worked for countless companies to include CompTIA, Entrepreneur Magazine, Microsoft, McGraw Hill Education, Cisco, the National Security Agency and Digidesign. Rob has an extremely diverse background in the print media industry filling roles such as author, co-author, technical editor, copy editor and…    

Names and Data Elements
Watch the Length of Names
Avoid All Special Characters in Names
Avoid Quoted Identifiers
Enforce Capitalization Rules to Avoid Case-Sensitivity Problems
Follow the ISO-11179 Standards Naming Conventions
ISO-11179 for SQL
Levels of Abstraction
Avoid Descriptive Prefixes
Develop Standardized Postfixes
Table and View Names Should Be Industry Standards, Collective, Class, or Plural Nouns
Correlation Names Follow the Same Rules as Other Names... Almost
Relationship Table Names Should Be Common Descriptive Terms
Metadata Schema Access Objects Can Have Names That Include Structure Information
Problems in Naming Data Elements
Avoid Vague Names
Avoid Names That Change from Place to Place
Do Not Use Proprietary Exposed Physical Locators
Fonts, Punctuation, and Spacing
Typography and Code
Use Only Upper- and Lowercase Letters, Digits, and Underscores for Names
Lowercase Scalars Such as Column Names, Parameters, and Variables
Capitalize Schema Object Names
Uppercase the Reserved Words
Avoid the Use of CamelCase
Word Spacing
Follow Normal Punctuation Rules
Use Full Reserved Words
Avoid Proprietary Reserved Words if a Standard Keyword Is Available in Your SQL Product
Avoid Proprietary Statements if a Standard Statement Is Available
Rivers and Vertical Spacing
Use Line Spacing to Group Statements
Data Declaration Language
Put the Default in the Right Place
The Default Value Should Be the Same Data Type as the Column
Do Not Use Proprietary Data Types
Place the PRIMARY KEY Declaration at the Start of the CREATE TABLE Statement
Order the Columns in a Logical Sequence and Cluster Them in Logical Groups
Indent Referential Constraints and Actions under the Data Type
Give Constraints Names in the Production Code
Put CHECK() Constraint Near what they Check
Consider Range Constraints for Numeric Values
Consider LIKE and SIMILAR TO Constraints for Character Values
Remember That Temporal Values Have Duration
REAL and FLOAT Data Types Should Be Avoided
Put Multiple Column Constraints as Near to Both Columns as Possible
Put Table-Level CHECK() Constraints at the End of the Table Declaration
Use CREATE ASSERTION for Multi-table Constraints
Keep CHECK() Constraints Single Purposed
Every Table Must Have a Key to Be a Table
Auto-Numbers Are Not Relational Keys
Files Are Not Tables
Look for the Properties of a Good Key
Do Not Split Attributes
Split into Tables
Split into Columns
Split into Rows
Do Not Use Object-Oriented Design for an RDBMS
A Table Is Not an Object Instance
Do Not Use EAV Design for an RDBMS
Scales and Measurements
Measurement Theory
Range and Granularity
Granularity, Accuracy, and Precision
Types of Scales
Nominal Scales
Categorical Scales
Absolute Scales
Ordinal Scales
Rank Scales
Interval Scales
Ratio Scales
Using Scales
Scale Conversion
Derived Units
Punctuation and Standard Units
General Guidelines for Using Scales in a Database
Data Encoding Schemes
Bad Encoding Schemes
Encoding Scheme Types
Enumeration Encoding
Measurement Encoding
Abbreviation Encoding
Algorithmic Encoding
Hierarchical Encoding Schemes
Vector Encoding
Concatenation Encoding
General Guidelines for Designing Encoding Schemes
Existing Encoding Standards
Allow for Expansion
Use Explicit Missing Values to Avoid NULLs
Translate Codes for the End User
Keep the Codes in the Database
Multiple Character Sets
Coding Choices
Pick Standard Constructions over Proprietary Constructions
Use Standard OUTER JOIN Syntax
Infixed INNER JOIN and CROSS JOIN Syntax Is Optional, but Nice
Use ISO Temporal Syntax
Use Standard and Portable Functions
Pick Compact Constructions over Longer Equivalents
Avoid Extra Parentheses
Use CASE Family Expressions
Avoid Redundant Expressions
Seek a Compact Form
Use Comments
Stored Procedures
Control Statement Comments
Comments on Clause
Avoid Optimizer Hints
Avoid Triggers in Favor of DRI Actions
Use SQL Stored Procedures
Avoid User-Defined Functions and Extensions inside the Database
Multiple Language Problems
Portability Problems
Optimization Problems
Avoid Excessive Secondary Indexes
Avoid Correlated Subqueries
Avoid UNIONs
Testing SQL
Test All Possible Combinations of NULLs
Inspect and Test All CHECK() Constraints
Beware of Character Columns
Test for Size
How to Use VIEWS
VIEW Naming Conventions Are the Same as Tables
Always Specify Column Names
VIEWs Provide Row- and Column-Level Security
VIEWs Ensure Efficient Access Paths
VIEWs Mask Complexity from the User
VIEWs Ensure Proper Data Derivation
VIEWs Rename Tables and/or Columns
VIEWs Enforce Complicated Integrity Constraints
Updatable VIEWs
Have a Reason for Each VIEW
Avoid VIEW Proliferation
Synchronize VIEWs with Base Tables
Improper Use of VIEWs
VIEWs for Domain Support
Single-Solution VIEWs
Do Not Create One VIEW Per Base Table
Learn about Materialized VIEWs
How to Write Stored Procedures
Most SQL 4GLs Are Not for Applications
Basic Software Engineering
Use Classic Structured Programming
Cyclomatic Complexity
Avoid Portability Problems
Avoid Creating Temporary Tables
Avoid Using Cursors
Prefer Set-Oriented Constructs to Procedural Code
Scalar versus Structured Parameters
Avoid Dynamic SQL
SQL Injection
Put the Specification into a Clear Statement
Add the Words "Set of All..." in Front of Nouns
Remove Active Verbs from the Problem Statement
You Can Still Use Stubs
Do Not Worry about Displaying the Data
Your First Attempts Need Special Handling
Do Not Be Afraid to Throw Away Your First Attempts at DDL
Save Your First Attempts at DML
Do Not Think with Boxes and Arrows
Draw Circles and Set Diagrams
Learn Your Dialect
Imagine That Your WHERE Clause Is "Super Ameba"
Use the Newsgroups and Internet
Thinking in SQL
Bad Programming in SQL and Procedural Languages
Thinking of Columns as Fields
Thinking in Processes, Not Declarations
Thinking the Schema Should Look Like the Input Forms
Military Standards
Metadata Standards
ANSI and ISO Standards
U.S. Government Codes
Retail Industry
Code Formatting and Naming Conventions
Reading Psychology
Programming Considerations
About the Author