超实用的sql书写规范大全sql标准格式

SQL编码样式书写规范指南（全）SQL是数据库查询语言，MIMIC、eICU数据库等数据提取可以使用SQL语言来提取，今天分享一篇文档，主要介绍SQL编程需要注意的事项。以下是正文。目

录1.Overview综述2.General一般原则2.1Do应该做的事情2.2Avoid应避免的事情3.Namingconventions命名惯例3.1General一般原则3.2Tables表名3.3Columns列名3.4Aliasingorcorrelations别名与关联名3.5Storedprocedures存储过程名3.6Uniformsuffix统一的后缀4.Querysyntax查询语句4.1Reservedwords保留字4.2Whitespace空白字符4.3Indentation缩进4.4Preferredformalisms推荐的形式5.Createsyntax创建语句5.1Choosingdatatypes选择数据类型5.2Specifyingdefaultvalues指定默认类型5.3Constraintsandkeys约束和键5.4Designtoavoid应该避免的设计6.附录6.1Columndatatypes列的数据类型这篇文档翻译自以署名-相同方式共享4.0国际协议发布的sqlstyle.guide，译文以与原文同样的协议发布。bySimonHolywell·@Treffynnon

Translatedby:wontoncoder·penghou6201.Overview综述你可以直接使用这些指导方针，或者fork后创建自己的版本——最重要的是选择一套方针并严格遵守它。欢迎通过在GitHub上提交issue或pullrequest来提交建议或修复bug。为了让阅读了JoeCelko的《SQLProgrammingStyle》的团队能更容易采用这套规则，这套原则被设计成与该书兼容的形式。本指南在某些领域严一些，在另一些领域松一些。当然本指南比Celko的书更简洁一些——因为Celko的书包含了一些趣闻和每一条原则后的理由。将该文档的Markdown格式添加到项目代码库中或将该页面的链接发送给项目的所有参与者要比传阅实体书容易得多。SimonHolywell所著的《SQL样式指南》以署名-相同方式共享4.0国际协议发布，改编自sqlstyle.guide。2.General一般原则2.1Do应该做的事情使用一致的、描述性的名称。合理地使用空格和缩进来增强可读性。存储符合ISO-8601标准的日期格式（YYYY-MM-DDHH:MM:SS.SSSSS）。为了提高可移植性，最好仅使用标准SQL函数而不是特定供应商的函数。保证代码简洁明了、没有多余的SQL——比如非必要的引号或括号，或者可以推导出的WHERE子句。必要时在SQL代码中加入注释。优先使用C语言式的以/*开始以*/结束的块注释，或使用以--开始的行注释，并在末尾换行。SELECT

file_hash

--

stored

ssdeep

hash

FROM

file_system

WHERE

file_name

=

'.vimrc';/*

Updating

the

file

record

after

writing

to

the

file

*/

UPDATE

file_system

SET

file_modified_date

=

'1980-02-22

13:19:01.00000',

file_size

=

209732

WHERE

file_name

=

'.vimrc';2.2Avoid应避免的事情驼峰命名法，它不适合快速扫读。描述性的前缀或匈牙利命名法比如sp_或tbl。复数形式，尽量使用更自然的集合术语。比如，用“staff”替代“employees”，或用“people”替代“individuals”。被引号包裹的标识符（quotedidentifier），如果你必须使用这样的标识符，最好坚持用SQL92的双引号来提高可移植性（你可能需要配置你的SQL服务器以支持此特性，具体取决于供应商）。面向对象编程的原则不该应用到SQL或数据库结构上。3.Namingconventions命名惯例3.1General一般原则保证名字独一无二且不是保留字。保证名字长度不超过30个字节，实际上，如果你不使用多字节字符集，就是30个字符。名字要以字母开头，不能以下划线结尾。只在名字中使用字母、数字和下划线。不要在名字中出现连续下划线，这样很难辨认。在名字中需要空格的地方用下划线代替（firstname变为first_name）。尽量避免使用缩写词。使用时一定确定这个缩写简明易懂。SELECT

first_name

FROM

staff;3.2Tables表名使用集合名称，或在不那么理想的情况下使用复数形式。如staff（建议使用）和employees。不要使用类似tbl或其他的描述性的前缀或匈牙利命名法。表不应该同它的列同名，反之亦然。尽量避免连接两个表的名字作为关系表（relationshiptable）的名字。与其使用cars_mechanics做表名不如使用services。3.3Columns列名总是使用单数形式。避免直接使用id做表的主标识符。避免列名和表名同名，反之亦然。总是使用小写字母，除非是特殊情况，如专有名词。3.4Aliasingorcorrelations别名与关联名别名应该与它们所指的对象或表达式相关联。一般来说，关联名应该由对象名中每一个单词的首字母组成。如果已经有相同的关联名了，那么在关联名后加一个数字。总是加上AS关键字，因为这样的明确声明易于阅读。为计算出的数据（SUM()或AVG()）命名时，用一个将这条数据存在表中时会使用的列名。SELECT

first_name

AS

fn

FROM

staff

AS

s1

JOIN

students

AS

s2

ON

s2.mentor_id

=

s1.staff_num;SELECT

SUM(s.monitor_tally)

AS

monitor_total

FROM

staff

AS

s;3.5Storedprocedures存储过程名名字一定要包含动词。不要附加sp_或任何其他这样的描述性的前缀或使用匈牙利表示法。3.6Uniformsuffix统一的后缀下列后缀有统一的意义，能保证SQL代码更容易理解。在合适的时候使用正确的后缀。_id——独一无二的标识符，如主键。_status——标志值或任何表示状态的值，比如publication_status。_total——总和或某些值的和。_num——表示该字段包含数值。_name——表示名字，例如first_name。_seq——包含一系列值。_date——表示该列包含日期。_tally——计数值。_size——大小，如文件大小或服装大小。_addr——地址，有形的或无形的，如ip_addr4.Querysyntax查询语句4.1Reservedwords保留字关键字总是大写，如SELECT和WHERE。最好使用关键字的全称而不是简写，用ABSOLUTE而不用ABS。当标准ANSISQL关键字能完成相同的事情时，不要使用数据库服务器特定的关键字，这样能增强可移植性。SELECT

model_num

FROM

phones

AS

p

WHERE

p.release_date

>

'2014-09-30';4.2Whitespace空白字符正确地使用空白字符对清晰的代码十分重要。不要把代码堆在一起或移除自然语言中的空格。4.2.1Spaces空格用空格使根关键字都结束在同一列上。在代码中间形成一个从上到下的“川流”，这样帮助读者快速扫视代码并将关键字和实现细节分开。川流在排版时应该避免，但是对阅读SQL语句是有帮助的。(SELECT

f.species_name,

AVG(f.height)

AS

average_height,

AVG(f.diameter)

AS

average_diameter

FROM

flora

AS

f

WHERE

f.species_name

=

'Banksia'

OR

f.species_name

=

'Sheoak'

OR

f.species_name

=

'Wattle'

GROUP

BY

f.species_name,

f.observation_date)

UNION

ALL

(SELECT

b.species_name,

AVG(b.height)

AS

average_height,

AVG(b.diameter)

AS

average_diameter

FROM

botanic_garden_flora

AS

b

WHERE

b.species_name

=

'Banksia'

OR

b.species_name

=

'Sheoak'

OR

b.species_name

=

'Wattle'

GROUP

BY

b.species_name,

b.observation_date);注意SELECT和FROM等关键字，都右对齐，而实际的列名和实现细节都左对齐。注意下列情况总是加入空格：在等号（=）前后在逗号（,）后成对的单引号（'）前后，除非在括号中或后面是逗号/分号SELECT

a.title,

a.release_date,

a.recording_date

FROM

albums

AS

a

WHERE

a.title

=

'Charcoal

Lane'

OR

a.title

=

'The

New

Danger';4.2.2Linespacing换行总是换行的情况：在AND或OR前在分号后（分隔语句以提高可读性）在每个关键字定义之后将多个列组成一个逻辑组时的逗号后将代码分隔成相关联的多个部分，帮助提高大段代码的可读性让所有的关键字右对齐、所有的值左对齐，这样就能在查询语句中间留出一个空隙，有助于快速扫读整个查询的定义。INSERT

INTO

albums

(title,

release_date,

recording_date)

VALUES

('Charcoal

Lane',

'1990-01-01

01:01:01.00000',

'1990-01-01

01:01:01.00000'),

('The

New

Danger',

'2008-01-01

01:01:01.00000',

'1990-01-01

01:01:01.00000');UPDATE

albums

SET

release_date

=

'1990-01-01

01:01:01.00000'

WHERE

title

=

'The

New

Danger';SELECT

a.title,

a.release_date,

a.recording_date,

duction_date

--

将所有的日期放在一起

FROM

albums

AS

a

WHERE

a.title

=

'Charcoal

Lane'

OR

a.title

=

'The

New

Danger';4.3Indentation缩进为确保SQL的可读性，一定要遵守下列规则。4.3.1JoinsJoin语句Join语句应该缩进到川流的另一侧并在必要的时候添加一个换行。SELECT

r.last_name

FROM

riders

AS

r

INNER

JOIN

bikes

AS

b

ON

r.bike_vin_num

=

b.vin_num

AND

b.engine_tally

>

2

INNER

JOIN

crew

AS

c

ON

r.crew_chief_last_name

=

c.last_name

AND

c.chief

=

'Y';4.3.2Subqueries子查询子查询应该在川流的右侧对齐并使用其他查询相同的样式。有时候将右括号单独置于一行并同与它配对的左括号对齐是有意义的——尤其是当存在嵌套子查询的时候。SELECT

r.last_name,

(SELECT

MAX(YEAR(championship_date))

FROM

champions

AS

c

WHERE

c.last_name

=

r.last_name

AND

c.confirmed

=

'Y')

AS

last_championship_year

FROM

riders

AS

r

WHERE

r.last_name

IN

(SELECT

c.last_name

FROM

champions

AS

c

WHERE

YEAR(championship_date)

>

'2008'

AND

c.confirmed

=

'Y');4.4Preferredformalisms推荐的形式尽量使用BETWEEN而不是多个AND语句。同样地，使用IN()而不是多个OR语句。当数据输出数据库时需要处理时，使用CASE表达式。CASE语句能嵌套形成更复杂的逻辑结构。尽量避免UNION语句和临时表。如果数据库架构能够不靠这些语句运行，那么多数情况下它就不应该依靠这些语句。SELECT

CASE

postcode

WHEN

'BN1'

THEN

'Brighton'

WHEN

'EH1'

THEN

'Edinburgh'

END

AS

city

FROM

office_locations

WHERE

country

=

'United

Kingdom'

AND

opening_time

BETWEEN

8

AND

9

AND

postcode

IN

('EH1',

'BN1',

'NN1',

'KW1');5.Createsyntax创建语句声明模式信息时维护可读代码也很重要。所以列定义的顺序和分组一定要有意义。在CREATE定义中，每个列定义要缩进4个空格。5.1Choosingdatatypes选择数据类型尽量不使用供应商相关的数据类型——这些类型不可移植甚至有可能不能在相同供应商的旧版本系统上使用。只在真的需要浮点数运算的时候才使用REAL和FLOAT类型，否则使用NUMERIC和DECIMAL类型。浮点数舍入误差是个麻烦。5.2Specifyingdefaultvalues指定默认类型默认值一定与列的类型相同——如果一个列的类型是DECIMAL那么就不要使用INTEGER类型的值作为默认值。默认值要紧跟类型声明并在NOTNULL声明前。5.3Constraintsandkeys约束和键约束和键是构成数据库系统的重要组成部分。它们能很快地变得难以阅读和理解，所以遵从指导方针是很重要的。5.3.1Choosingkeys选择键设计时应该谨慎选择构成键的列，因为键会影响性能和数据完整性。键在某种程度上应该是独一无二的。该值在不同表中的类型应该相同并且尽量不会更改。该值能否通过某种标准格式（如ISO发布的标准）？鼓励与前面第二点一致。尽量让键保持简单，但在适当情况下不要害怕使用复合键。以上是定义数据库时合乎逻辑的平衡做法。当需求变更时，键也应该根据情况更新。5.3.2Definingconstraints定义约束确定键后，就可以用约束和字值段验证来定义它们。General概述表至少需要一个键来保证其完整性和可用性。除了UNIQUE、PRIMARYKEY和FOREIGNKEY之外（数据库供应商会提供相应的检查），约束应该有名字。Layoutandorder布局和顺序在CREATETABLE语句后先定义主键。约束的定义应该紧跟它相应的列的定义后。如果该约束与多个列相关，那么让它离相关的列越近越好。实在不行就将它放在表定义的最后。如果是应用于整个表的表级别的约束，那么就将它放在表定义的最后。按照字母顺序安排定义，ONDELETE排在ONUPDATE前。有道理的话，把所有相关的语句对齐。比如，把所有NOTNULL定义对齐到同一列。这样做并不难，但是能提高可读性。Validation校验当字符串的格式已知时，用LIKE和SIMILARTO约束来保证它们的完整性。当数值的范围可以确定时，用范围CHECK()来防止错误的值进入数据库或在没有提示的情况下截断。大部分情况下至少要确认数值大于零。CHECK()约束应该在单独的子句中以便debug。CREATE

TABLE

staff

(

PRIMARY

KEY

(staff_num),

staff_num

INT(5)

NOT

NULL,

first_name

VARCHAR(100)