SQL样式指南·SQL Style Guide

Overview 综述

你可以直接使用这些指导方针，或者fork后创建自己的版本——最重要的是选择一套方针并严格遵守它。欢迎通过提交issue或pull request来提交建议或修复bug。

为了让阅读了Joe Celko的《SQL ProgrammingStyle》的团队能更容易采用这套规则， 这套原则被设计成与该书的兼容的形式。该指南在某些领域严格一些，在另一些领域松懈一些。 当然该指南比Celko的书更简洁一些，因为Celko的书包含了一些趣闻和每一条原则后的理由。

将该文档的Markdown format格式添加到项目代码库中或将该页面的链接发送给所有项目的参与者要比传阅实体书容易得多。

General 一般原则

Do 应该做的事情

使用一致的、叙述性的名称。

灵活使用空格和缩进来增强可读性。

存储符合ISO-8601标准的日期格式()。

最好使用标准SQL函数而不是特定供应商的函数以提高可移植性。

保证代码简洁明了并消除多余的SQL——比如非必要的引号或括号，或者可以推导出的多余语句。

必要时在SQL代码中加入注释。优先使用C语言式的以开始以结束的块注释，或使用以开始的行注释。

Avoid 应避免的事情

驼峰命名法——它不适合快速扫描。

描述性的前缀或匈牙利命名法比如或。

复数形式——尽量使用更自然的集合术语。比如，用“staff”替代“employees”，或用“people”替代“individuals”。

需要引用号的标识符——如果你必须使用这样的标识符，最好坚持用SQL92的双引号来提高可移植性。

面向对象编程的原则不该应用到结构化查询语言或数据库结构上。

Naming conventions 命名惯例

General 一般原则

保证名字独一无二且不是保留字。

保证名字长度不超过30个字节。

名字要以字母开头，不能以下划线结尾。

只在名字中使用字母、数字和下划线。

不要在名字中出现连续下划线——这样很难辨认。

在名字中需要空格的地方用下划线代替。

尽量避免使用缩写词。使用时一定确定这个缩写简明易懂。

Tables 表名

用集群名称，或在不那么理想的情况下，复数形式。如和。

不要使用类似或其他的描述性的前缀或匈牙利命名法。

表不应该同它的列同名，反之亦然。

尽量避免连接两个表的名字作为关系表（relationship table）的名字。与其使用做表名不如使用。

Columns 列名

总是使用单数形式。

避免直接使用做表的主标识符。

避免列名同表名同名，反之亦然。

总是使用小写字母，除非是特殊情况，如专有名词。

Aliasing or correlations 别名与关联名

应该与它们别名的对象或与它们代表的表达式相关联。

一般来说，关联名应该是对象名的第一个字母。

如果已经有相同的关联名了，那么在关联名后加一个数字。

总是加上关键字，因为这样的显示声明易于阅读。

为计算出的数据命名时，用一个将这条数据存在表里时会使用的列名。

Stored procedures 过程名

名字一定要包含动词。

不要附加或任何其他这样的叙述性前缀或使用匈牙利表示法。

Uniform suffix 统一的后缀

下列后缀有统一的意义，能保证SQL代码更容易被理解。在合适的时候使用正确的后缀。

独一无二的标识符，如主键。

标识值或任何表示状态的值，比如。

总和或某些值的和。

表示该域包含数值。

表示名字。

包含一系列数值。

表示该列包含日期。

计数值。

大小，如文件大小或服装大小。

地址，有形的或无形的，如

Query syntax 查询语句

Reserved words 保留字

保留字总是大写，如和。

最好使用保留字的全称而不是简写，用而不用。

当标准ANSI SQL关键字能完成相同的事情时，不要使用数据库服务器相关的关键字，这样能增强可移植性。

White space 空白字符

正确地使用空白字符对清晰的代码十分重要。不要把代码堆再一起或移除自然语言中的空格。

Spaces 空格

用空格使根关键字都结束在同一列上。在代码中形成一个从上到下的“川流”，这样帮助读者快速扫描代码并将关键字和实现细节分开。川流在排版时应该避免，但是对书写SQL语句是有帮助的。

注意和等关键字，都右对齐，而真实的列名都左对齐。

注意下列情况总是加入空格：

在等号前后（）

在逗号后（）

单引号前后（），除非单引号后面是括号、逗号或分号

Line spacing 换行

总是换行的情况：

在或前。

在分号后（分隔语句以提高可读性）。

在每个关键词定以后。

将多个列组成一个逻辑组时的逗号后。

将代码分隔成相关联的多个部分，帮助提高大段代码的可读性。

让所有的关键字右对齐，让所有的值左对齐，在查询语句中间留出一个空隙。这样能提高速读代码的速读。

Identation 缩进

为确保SQL的可读性，一定要遵守下列规则。

Joins Join语句

Join语句应该缩进到川流的另一侧并在必要的时候添加一个换行。

Subqueries 子查询

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

Preferred formalisms 推荐的形式

尽量使用而不是多个语句。

同样地，使用而不是多个语句。

当数据输出数据库时需要处理时，使用表达式。语句能嵌套形成更复杂的逻辑结构。

尽量避免语句和临时表。如果数据库架构能够不靠这些语句运行，那么多数情况下它就不应该依靠这些语句。

Create syntax 创建语句

声明模式信息时维护可读代码也很重要。所以列定义的顺序和分组一定要有意义。

在定义中，每列要缩进4个空格。

Choosing data types 选择数据类型

尽量不使用供应商相关的数据类型——这些类型可不能能在老系统上使用。

只在真的需要浮点数运算的时候才使用和类型，否则使用和类型。浮点数舍入误差是个麻烦。

Specifying default values 指定默认类型

默认值一定与列的类型相同——如果一个列的类型是那么就不要使用类型作为默认值。

默认值要紧跟类型声明并在声明前。

约束和键

约束和键是构成数据库系统的重要组成部分。它们能很快地变得难以阅读和理解，所以遵从指导方针是很重要的。

Choosing keys 选择键

设计时应该谨慎选择构成键的列，因为键既明显影响着性能和数据完整性。

键在某种程度上应该是独一无二的。

该值在不同表中的类型应该相同并且尽量不会更改。

该值是否会无法通过某种标准格式（如ISO发布的标准）？如

尽量让键保持简单，但在适当情况下不要害怕使用复合键。

以上是定义数据库时合乎逻辑的平衡做法。当需求变更时，键也应该根据情况更新。

Defining constraints 定义约束

确定键后，就可以用约束和字值段验证来定义它们。

General 概述

表至少需要一个键来保证其完整性和可用性。

约束应该有名字，除了、和之外。

Layout and order 布局和顺序

在语句后先定义主键。

约束的定义应该紧跟它相应的列的定义后。

如果该约束与多个列相关，那么让它尽量离与其相关的列距离越近越好。实在不行就讲它放在表定义的最后。

如果是与整个表相关联表级别的约束，那么就将放在表的定义的最后。

按照字母顺序安排定义，排在前。

有道理的话，把所有相关的语句对齐。比如，把所有定义对齐到同一列。虽然这样的做法有些慢，但是能提高可读性。

Validation 校验

用和约束来保证格式已知字符串的数据完整性。

当数字的值的范围可以确定时，用来防止错误的值进入数据库或被错误地转换。大部分情况下至少要确认值要大于零。

约束应该在单独的语句中以便debug。

Example

Design to avoid

面向对象设计思想并不适用于关系型数据库——避免这个陷阱。

将值存入一列并将单位存在另一列。列的定义应该让自己的单位不言自明以避免在应用内进行合并。使用来保证数据库中的数据是合法的。

EAV (Entity Attribute Value)表——用特殊的产品来处理无模式数据。

因为某些原因（如为了归档、为了划分跨国公司的区域）将能合并在一起的表分开。这样的设计导致以后必须使用操作而不能直接查询一个表。