LEADER 05595nam 2200721Ia 450 001 9910458675103321 005 20200520144314.0 010 $a1-281-00810-9 010 $a9786611008109 010 $a1-4237-2245-0 010 $a0-08-047883-2 035 $a(CKB)1000000000364641 035 $a(EBL)234986 035 $a(OCoLC)171114272 035 $a(SSID)ssj0000185817 035 $a(PQKBManifestationID)11182450 035 $a(PQKBTitleCode)TC0000185817 035 $a(PQKBWorkID)10210537 035 $a(PQKB)10239425 035 $a(MiAaPQ)EBC234986 035 $a(CaSebORM)9780120887972 035 $a(Au-PeEL)EBL234986 035 $a(CaPaEBR)ebr10127897 035 $a(CaONFJC)MIL100810 035 $a(OCoLC)936903670 035 $a(EXLCZ)991000000000364641 100 $a20050225d2005 uy 0 101 0 $aeng 135 $aur|n|---||||| 181 $ctxt 182 $cc 183 $acr 200 10$aJoe Celko's SQL programming style$b[electronic resource] /$fJoe Celko 205 $a1st edition 210 $aAmsterdam ;$aBoston $cElsevier$d2005 215 $a1 online resource (236 p.) 225 1 $aThe Morgan Kaufmann Series in Data Management Systems 300 $aDescription based upon print version of record. 311 $a0-12-088797-5 320 $aIncludes bibliographical references (p. [203]-206) and index. 327 $aFront cover; Title page; Copyright page; Table of contents; front matter; Introduction; 1.1 Purpose of the Book; 1.2 Acknowledgments; 1.3 Corrections, Comments, and Future Editions; First chapter; 1. Names and Data Elements; 1.1 Names; 1.1.1 Watch the Length of Names; 1.1.2 Avoid All Special Characters in Names; 1.1.3 Avoid Quoted Identifiers; 1.1.4 Enforce Capitalization Rules to Avoid Case- Sensitivity Problems; 1.2 Follow the ISO-11179 Standards Naming Conventions; 1.2.1 ISO-11179 for SQL; 1.2.2 Levels of Abstraction; 1.2.3 Avoid Descriptive Prefixes; 1.2.4 Develop Standardized Postfixes 327 $a1.2.5 Table and View Names Should Be Industry Standards, Collective, Class, or Plural Nouns1.2.6 Correlation Names Follow the Same Rules as Other Names . . . Almost; 1.2.7 Relationship Table Names Should Be Common Descriptive Terms; 1.2.8 Metadata Schema Access Objects Can Have Names That Include Structure Information; 1.3 Problems in Naming Data Elements; 1.3.1 Avoid Vague Names; 1.3.2 Avoid Names That Change from Place to Place; 1.3.3 Do Not Use Proprietary Exposed Physical Locators; 2. Fonts, Punctuation, and Spacing; 2.1 Typography and Code 327 $a2.1.1 Use Only Upper- and Lowercase Letters, Digits, and Underscores for Names2.1.2 Lowercase Scalars Such as Column Names, Parameters, and Variables; 2.1.3 Capitalize Schema Object Names; 2.1.4 Uppercase the Reserved Words; 2.1.5 Avoid the Use of CamelCase; 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.8 Indentation; 2.9 Use Line Spacing to Group Statements 327 $a3. Data Declaration Language3.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.8.1 Consider Range Constraints for Numeric Values 327 $a3.8.2 Consider LIKE and SIMILAR TO Constraints for Character Values3.8.3 Remember That Temporal Values Have Duration; 3.8.4 REAL and FLOAT Data Types Should Be Avoided; 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.13.1 Auto-Numbers Are Not Relational Keys; 3.13.2 Files Are Not Tables; 3.13.3 Look for the Properties of a Good Key 327 $a3.14 Do Not Split Attributes 330 $aAre 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 SQ 410 4$aThe Morgan Kaufmann Series in Data Management Systems 517 3 $aSQL programming style 606 $aSQL (Computer program language) 606 $aQuery languages (Computer science) 608 $aElectronic books. 615 0$aSQL (Computer program language) 615 0$aQuery languages (Computer science) 676 $a005.13/3 700 $aCelko$b Joe$0627493 801 0$bMiAaPQ 801 1$bMiAaPQ 801 2$bMiAaPQ 906 $aBOOK 912 $a9910458675103321 996 $aJoe Celko's SQL programming style$91939261 997 $aUNINA