Differences

This shows you the differences between two versions of the page.

--- sql命名规范 [2018/07/10 10:14]
jordan
+++ sql命名规范 [2023/03/08 16:05] (current)
xujianglong ↷ Page moved from 内部资料:sql命名规范 to sql命名规范
@@ Line 1: / Line 1: @@
 参照：
-* [SQL样式指南](http://www.sqlstyle.guide/zh/)
+  * [[http://www.sqlstyle.guide/zh/|SQL样式指南]]
-* [MySQL internal Coding Style](https://dev.mysql.com/doc/internals/en/coding-style.html)
+  * [[https://dev.mysql.com/doc/internals/en/coding-style.html|MySQL internal Coding Style]]
-# SQL style guide SQL样式指南
+====== SQL style guide SQL样式指南 ======
-这篇文档翻译自以[署名-相同方式共享 4.0 国际协议][licence-zh]发布的[http://www.sqlstyle.guide][sqlstyleguide]，译文以原文同样的协议发布。
+这篇文档翻译自以[[https://creativecommons.org/licenses/by-sa/4.0/deed.zh|署名-相同方式共享 4.0 国际协议]]发布的http://www.sqlstyle.guide，译文以原文同样的协议发布。
-## Overview 综述
+===== Overview 综述 =====
-你可以直接使用这些指导方针，或者[fork][fork]后创建自己的版本——最重要的是选择一套方针并严格遵守它。欢迎通过提交[issue][issue]或[pull request][pull]来提交建议或修复bug。
+你可以直接使用这些指导方针，或者[[https://github.com/treffynnon/sqlstyle.guide/fork|fork]]后创建自己的版本——最重要的是选择一套方针并严格遵守它。欢迎通过提交[[https://github.com/treffynnon/sqlstyle.guide/issues|issue]]或[[https://github.com/treffynnon/sqlstyle.guide/pulls/|pull request]]来提交建议或修复bug。
-为了让阅读了Joe Celko的《[SQL ProgrammingStyle][celko]》的团队能更容易采用这套规则， 这套原则被设计成与该书的兼容的形式。该指南在某些领域严格一些，在另一些领域松懈一些。 当然该指南比Celko的书更简洁一些，因为Celko的书包含了一些趣闻和每一条原则后的理由。
+为了让阅读了Joe Celko的《[[https://www.amazon.com/gp/product/0120887975/ref=as_li_ss_tl?ie=UTF8&linkCode=ll1&tag=treffynnon-20&linkId=9c88eac8cd420e979675c815771313d5|SQL ProgrammingStyle]]》的团队能更容易采用这套规则， 这套原则被设计成与该书的兼容的形式。该指南在某些领域严格一些，在另一些领域松懈一些。 当然该指南比Celko的书更简洁一些，因为Celko的书包含了一些趣闻和每一条原则后的理由。
-将该文档的[Markdown format][dl-md]格式添加到项目代码库中或将该页面的链接发送给所有项目的参与者要比传阅实体书容易得多。
+将该文档的[[https://raw.githubusercontent.com/treffynnon/sqlstyle.guide/gh-pages/_includes/sqlstyle.guide.zh.md|Markdown format]]格式添加到项目代码库中或将该页面的链接发送给所有项目的参与者要比传阅实体书容易得多。
-[Simon Holywell][simon]所著的《SQL样式指南》以[署名-相同方式共享 4.0 国际协议][licence-zh]发布，改编自[http://www.sqlstyle.guide][sqlstyleguide]。
+[[https://www.simonholywell.com/?utm_source=sqlstyle.guide&utm_medium=link&utm_campaign=md-document|Simon Holywell]]所著的《SQL样式指南》以[[https://creativecommons.org/licenses/by-sa/4.0/deed.zh|署名-相同方式共享 4.0 国际协议]]发布，改编自http://www.sqlstyle.guide。
-## General 一般原则
+===== General 一般原则 =====
-### Do 应该做的事情
+==== Do 应该做的事情 ====
-* 使用一致的、叙述性的名称。
+  * 使用一致的、叙述性的名称。
-* 灵活使用空格和缩进来增强可读性。
+  * 灵活使用空格和缩进来增强可读性。
-* 存储符合[ISO-8601][iso-8601]标准的日期格式(`YYYY-MM-DD HH:MM:SS.SSSSS`)。
+  * 存储符合[[https://en.wikipedia.org/wiki/ISO_8601|ISO-8601]]标准的日期格式(''%%YYYY-MM-DD HH:MM:SS.SSSSS%%'')。
-* 最好使用标准SQL函数而不是特定供应商的函数以提高可移植性。
+  * 最好使用标准SQL函数而不是特定供应商的函数以提高可移植性。
-* 保证代码简洁明了并消除多余的SQL——比如非必要的引号或括号，或者可以推导出的多余`WHERE`语句。
+  * 保证代码简洁明了并消除多余的SQL——比如非必要的引号或括号，或者可以推导出的多余''%%WHERE%%''语句。
-* 必要时在SQL代码中加入注释。优先使用C语言式的以`/*`开始以`*/`结束的块注释，或使用以`--`开始的行注释。
+  * 必要时在SQL代码中加入注释。优先使用C语言式的以''%%/*%%''开始以''%%*/%%''结束的块注释，或使用以''%%--%%''开始的行注释。
-```sql
+<code sql>
 SELECT file_hash  -- stored ssdeep hash
   FROM file_system
  WHERE file_name = '.vimrc';
-```
+</code>
-```sql
+<code sql>
 /* Updating the file record after writing to the file */
 UPDATE file_system
@@ Line 40: / Line 40: @@
        file_size = 209732
  WHERE file_name = '.vimrc';
-```
+</code>
+==== Avoid 应避免的事情 ====
-### Avoid 应避免的事情
+  * 驼峰命名法——它不适合快速扫描。
+  * 描述性的前缀或匈牙利命名法比如''%%sp_%%''或''%%tbl%%''。
+  * 复数形式——尽量使用更自然的集合术语。比如，用“staff”替代“employees”，或用“people”替代“individuals”。
+  * 需要引用号的标识符——如果你必须使用这样的标识符，最好坚持用SQL92的双引号来提高可移植性。
+  * 面向对象编程的原则不该应用到结构化查询语言或数据库结构上。
-* 驼峰命名法——它不适合快速扫描。
+===== Naming conventions 命名惯例 =====
-* 描述性的前缀或匈牙利命名法比如`sp_`或`tbl`。
-* 复数形式——尽量使用更自然的集合术语。比如，用“staff”替代“employees”，或用“people”替代“individuals”。
-* 需要引用号的标识符——如果你必须使用这样的标识符，最好坚持用SQL92的双引号来提高可移植性。
-* 面向对象编程的原则不该应用到结构化查询语言或数据库结构上。
-## Naming conventions 命名惯例
+==== General 一般原则 ====
-### General 一般原则
+  * 保证名字独一无二且不是[[#reserved-keyword-reference|保留字]]。
+  * 保证名字长度不超过30个字节。
+  * 名字要以字母开头，不能以下划线结尾。
+  * 只在名字中使用字母、数字和下划线。
+  * 不要在名字中出现连续下划线——这样很难辨认。
+  * 在名字中需要空格的地方用下划线代替。
+  * 尽量避免使用缩写词。使用时一定确定这个缩写简明易懂。
-* 保证名字独一无二且不是[保留字][reserved-keywords]。
+<code sql>
-* 保证名字长度不超过30个字节。
-* 名字要以字母开头，不能以下划线结尾。
-* 只在名字中使用字母、数字和下划线。
-* 不要在名字中出现连续下划线——这样很难辨认。
-* 在名字中需要空格的地方用下划线代替。
-* 尽量避免使用缩写词。使用时一定确定这个缩写简明易懂。
-```sql
 SELECT first_name
   FROM staff;
-```
+</code>
+==== Tables 表名 ====
-### Tables 表名
+  * 用集群名称，或在不那么理想的情况下，复数形式。如''%%staff%%''和''%%employees%%''。
+  * 不要使用类似''%%tbl%%''或其他的描述性的前缀或匈牙利命名法。
+  * 表不应该同它的列同名，反之亦然。
+  * 尽量避免连接两个表的名字作为关系表（relationship table）的名字。与其使用''%%cars_mechanics%%''做表名不如使用''%%services%%''。
-* 用集群名称，或在不那么理想的情况下，复数形式。如`staff`和`employees`。
+==== Columns 列名 ====
-* 不要使用类似`tbl`或其他的描述性的前缀或匈牙利命名法。
-* 表不应该同它的列同名，反之亦然。
-* 尽量避免连接两个表的名字作为关系表（relationship table）的名字。与其使用`cars_mechanics`做表名不如使用`services`。
-### Columns 列名
+  * 总是使用单数形式。
+  * 避免直接使用''%%id%%''做表的主标识符。
+  * 避免列名同表名同名，反之亦然。
+  * 总是使用小写字母，除非是特殊情况，如专有名词。
-* 总是使用单数形式。
+==== Aliasing or correlations 别名与关联名 ====
-* 避免直接使用`id`做表的主标识符。
-* 避免列名同表名同名，反之亦然。
-* 总是使用小写字母，除非是特殊情况，如专有名词。
-### Aliasing or correlations 别名与关联名
+  * 应该与它们别名的对象或与它们代表的表达式相关联。
+  * 一般来说，关联名应该是对象名的第一个字母。
+  * 如果已经有相同的关联名了，那么在关联名后加一个数字。
+  * 总是加上''%%AS%%''关键字，因为这样的显示声明易于阅读。
+  * 为计算出的数据命名时，用一个将这条数据存在表里时会使用的列名。
-* 应该与它们别名的对象或与它们代表的表达式相关联。
+<code sql>
-* 一般来说，关联名应该是对象名的第一个字母。
-* 如果已经有相同的关联名了，那么在关联名后加一个数字。
-* 总是加上`AS`关键字，因为这样的显示声明易于阅读。
-* 为计算出的数据命名时，用一个将这条数据存在表里时会使用的列名。
-```sql
 SELECT first_name AS fn
   FROM staff AS s1
   JOIN students AS s2
     ON s2.mentor_id = s1.staff_num;
-```
+</code>
-```sql
+<code sql>
 SELECT SUM(s.monitor_tally) AS monitor_total
   FROM staff AS s;
-```
+</code>
+==== Stored procedures 过程名 ====
-### Stored procedures 过程名
-* 名字一定要包含动词。
+  * 名字一定要包含动词。
-* 不要附加`sp_`或任何其他这样的叙述性前缀或使用匈牙利表示法。
+  * 不要附加''%%sp_%%''或任何其他这样的叙述性前缀或使用匈牙利表示法。
-### Uniform suffix 统一的后缀
+==== Uniform suffix 统一的后缀 ====
 下列后缀有统一的意义，能保证SQL代码更容易被理解。在合适的时候使用正确的后缀。
-* `_id` 独一无二的标识符，如主键。
+  * ''%%_id%%'' 独一无二的标识符，如主键。
-* `_status` 标识值或任何表示状态的值，比如`publication_status`。
+  * ''%%_status%%'' 标识值或任何表示状态的值，比如''%%publication_status%%''。
-* `_total` 总和或某些值的和。
+  * ''%%_total%%'' 总和或某些值的和。
-* `_num` 表示该域包含数值。
+  * ''%%_num%%'' 表示该域包含数值。
-* `_name` 表示名字。
+  * ''%%_name%%'' 表示名字。
-* `_seq` 包含一系列数值。
+  * ''%%_seq%%'' 包含一系列数值。
-* `_date` 表示该列包含日期。
+  * ''%%_date%%'' 表示该列包含日期。
-* `_tally` 计数值。
+  * ''%%_tally%%'' 计数值。
-* `_size` 大小，如文件大小或服装大小。
+  * ''%%_size%%'' 大小，如文件大小或服装大小。
-* `_addr` 地址，有形的或无形的，如`ip_addr`
+  * ''%%_addr%%'' 地址，有形的或无形的，如''%%ip_addr%%''
-## Query syntax 查询语句
+===== Query syntax 查询语句 =====
-### Reserved words 保留字
+==== Reserved words 保留字 ====
-保留字总是大写，如`SELECT`和`WHERE`。
+保留字总是大写，如''%%SELECT%%''和''%%WHERE%%''。
-最好使用保留字的全称而不是简写，用`ABSOLUTE`而不用`ABS`。
+最好使用保留字的全称而不是简写，用''%%ABSOLUTE%%''而不用''%%ABS%%''。
 当标准ANSI SQL关键字能完成相同的事情时，不要使用数据库服务器相关的关键字，这样能增强可移植性。
-```sql
+<code sql>
 SELECT model_num
   FROM phones AS p
  WHERE p.release_date > '2014-09-30';
-```
+</code>
+==== White space 空白字符 ====
-### White space 空白字符
 正确地使用空白字符对清晰的代码十分重要。不要把代码堆再一起或移除自然语言中的空格。
-#### Spaces 空格
+=== Spaces 空格 ===
 用空格使根关键字都结束在同一列上。在代码中形成一个从上到下的“川流”，这样帮助读者快速扫描代码并将关键字和实现细节分开。川流在排版时应该避免，但是对书写SQL语句是有帮助的。
-```sql
+<code sql>
 (SELECT f.species_name,
         AVG(f.height) AS average_height, AVG(f.diameter) AS average_diameter
@@ Line 162: / Line 158: @@
      OR b.species_name = 'Wattle'
   GROUP BY b.species_name, b.observation_date)
-```
+</code>
+注意''%%WHERE%%''和''%%FROM%%''等关键字，都右对齐，而真实的列名都左对齐。
-注意`WHERE`和`FROM`等关键字，都右对齐，而真实的列名都左对齐。
 注意下列情况总是加入空格：
-* 在等号前后（`=`）
+  * 在等号前后（''%%=%%''）
-* 在逗号后（`,`）
+  * 在逗号后（''%%,%%''）
-* 单引号前后（`'`），除非单引号后面是括号、逗号或分号
+  * 单引号前后（''%%'%%''），除非单引号后面是括号、逗号或分号
-```sql
+<code sql>
 SELECT a.title, a.release_date, a.recording_date
   FROM albums AS a
  WHERE a.title = 'Charcoal Lane'
     OR a.title = 'The New Danger';
-```
+</code>
+=== Line spacing 换行 ===
-#### Line spacing 换行
 总是换行的情况：
-* 在`AND`或`OR`前。
+  * 在''%%AND%%''或''%%OR%%''前。
-* 在分号后（分隔语句以提高可读性）。
+  * 在分号后（分隔语句以提高可读性）。
-* 在每个关键词定以后。
+  * 在每个关键词定以后。
-* 将多个列组成一个逻辑组时的逗号后。
+  * 将多个列组成一个逻辑组时的逗号后。
-* 将代码分隔成相关联的多个部分，帮助提高大段代码的可读性。
+  * 将代码分隔成相关联的多个部分，帮助提高大段代码的可读性。
 让所有的关键字右对齐，让所有的值左对齐，在查询语句中间留出一个空隙。这样能提高速读代码的速读。
+<code sql>
-```sql
 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');
-```
+</code>
+<code sql>
-```sql
 UPDATE albums
    SET release_date = '1990-01-01 01:01:01.00000'
  WHERE title = 'The New Danger';
-```
+</code>
+<code sql>
-```sql
 SELECT a.title,
        a.release_date, a.recording_date, a.production_date -- grouped dates together
@@ Line 210: / Line 201: @@
  WHERE a.title = 'Charcoal Lane'
     OR a.title = 'The New Danger';
-```
+</code>
+==== Identation 缩进 ====
-### Identation 缩进
 为确保SQL的可读性，一定要遵守下列规则。
-### Joins Join语句
+==== Joins Join语句 ====
 Join语句应该缩进到川流的另一侧并在必要的时候添加一个换行。
+<code sql>
-```sql
 SELECT r.last_name
   FROM riders AS r
@@ Line 231: / Line 220: @@
        ON r.crew_chief_last_name = c.last_name
           AND c.chief = 'Y';
-```
+</code>
+=== Subqueries 子查询 ===
-#### Subqueries 子查询
 子查询应该在川流的右侧对齐并使用其他查询相同的样式。有时候将右括号单独置于一行并同与它配对的左括号对齐是有意义的——尤其是当存在嵌套子查询的时候。
-```sql
+<code sql>
 SELECT r.last_name,
        (SELECT MAX(YEAR(championship_date))
@@ Line 249: / Line 237: @@
          WHERE YEAR(championship_date) > '2008'
            AND c.confirmed = 'Y');
-```
+</code>
+==== Preferred formalisms 推荐的形式 ====
-### Preferred formalisms 推荐的形式
+  * 尽量使用''%%BETWEEN%%''而不是多个''%%AND%%''语句。
+  * 同样地，使用''%%IN()%%''而不是多个''%%OR%%''语句。
+  * 当数据输出数据库时需要处理时，使用''%%CASE%%''表达式。''%%CASE%%''语句能嵌套形成更复杂的逻辑结构。
+  * 尽量避免''%%UNION%%''语句和临时表。如果数据库架构能够不靠这些语句运行，那么多数情况下它就不应该依靠这些语句。
-* 尽量使用`BETWEEN`而不是多个`AND`语句。
+<code sql>
-* 同样地，使用`IN()`而不是多个`OR`语句。
-* 当数据输出数据库时需要处理时，使用`CASE`表达式。`CASE`语句能嵌套形成更复杂的逻辑结构。
-* 尽量避免`UNION`语句和临时表。如果数据库架构能够不靠这些语句运行，那么多数情况下它就不应该依靠这些语句。
-```sql
 SELECT CASE postcode
        WHEN 'BN1' THEN 'Brighton'
@@ Line 268: / Line 254: @@
    AND opening_time BETWEEN 8 AND 9
    AND postcode IN ('EH1', 'BN1', 'NN1', 'KW1')
-```
+</code>
+===== Create syntax 创建语句 =====
-## Create syntax 创建语句
 声明模式信息时维护可读代码也很重要。所以列定义的顺序和分组一定要有意义。
-在`CREATE`定义中，每列要缩进4个空格。
+在''%%CREATE%%''定义中，每列要缩进4个空格。
-### Choosing data types 选择数据类型
+==== Choosing data types 选择数据类型 ====
-* 尽量不使用供应商相关的数据类型——这些类型可不能能在老系统上使用。
+  * 尽量不使用供应商相关的数据类型——这些类型可不能能在老系统上使用。
-* 只在真的需要浮点数运算的时候才使用`REAL`和`FLOAT`类型，否则使用`NUMERIC`和`DECIMAL`类型。浮点数舍入误差是个麻烦。
+  * 只在真的需要浮点数运算的时候才使用''%%REAL%%''和''%%FLOAT%%''类型，否则使用''%%NUMERIC%%''和''%%DECIMAL%%''类型。浮点数舍入误差是个麻烦。
-### Specifying default values 指定默认类型
+==== Specifying default values 指定默认类型 ====
-* 默认值一定与列的类型相同——如果一个列的类型是`DECIMAL`那么就不要使用`INTEGER`类型作为默认值。
+  * 默认值一定与列的类型相同——如果一个列的类型是''%%DECIMAL%%''那么就不要使用''%%INTEGER%%''类型作为默认值。
-* 默认值要紧跟类型声明并在`NOT NULL`声明前。
+  * 默认值要紧跟类型声明并在''%%NOT NULL%%''声明前。
-### Constraints and keys 约束和键
+==== Constraints and keys 约束和键 ====
 约束和键是构成数据库系统的重要组成部分。它们能很快地变得难以阅读和理解，所以遵从指导方针是很重要的。
-#### Choosing keys 选择键
+=== Choosing keys 选择键 ===
 设计时应该谨慎选择构成键的列，因为键既明显影响着性能和数据完整性。
-. 键在某种程度上应该是独一无二的。
+  - 键在某种程度上应该是独一无二的。
-. 该值在不同表中的类型应该相同并且尽量不会更改。
+  - 该值在不同表中的类型应该相同并且尽量不会更改。
-. 该值是否会无法通过某种标准格式（如ISO发布的标准）？如
+  - 该值是否会无法通过某种标准格式（如ISO发布的标准）？如
-. 尽量让键保持简单，但在适当情况下不要害怕使用复合键。
+  - 尽量让键保持简单，但在适当情况下不要害怕使用复合键。
 以上是定义数据库时合乎逻辑的平衡做法。当需求变更时，键也应该根据情况更新。
-#### Defining constraints 定义约束
+=== Defining constraints 定义约束 ===
 确定键后，就可以用约束和字值段验证来定义它们。
-##### General 概述
+== General 概述 ==
-* 表至少需要一个键来保证其完整性和可用性。
+  * 表至少需要一个键来保证其完整性和可用性。
-* 约束应该有名字，除了`UNIQUE`、`PRIMARY KEY`和`FOREIGN KEY`之外。
+  * 约束应该有名字，除了''%%UNIQUE%%''、''%%PRIMARY KEY%%''和''%%FOREIGN KEY%%''之外。
-##### Layout and order 布局和顺序
+== Layout and order 布局和顺序 ==
-* 在`CREATE TABLE`语句后先定义主键。
+  * 在''%%CREATE TABLE%%''语句后先定义主键。
-* 约束的定义应该紧跟它相应的列的定义后。
+  * 约束的定义应该紧跟它相应的列的定义后。
-* 如果该约束与多个列相关，那么让它尽量离与其相关的列距离越近越好。实在不行就讲它放在表定义的最后。
+  * 如果该约束与多个列相关，那么让它尽量离与其相关的列距离越近越好。实在不行就讲它放在表定义的最后。
-* 如果是与整个表相关联表级别的约束，那么就将放在表的定义的最后。
+  * 如果是与整个表相关联表级别的约束，那么就将放在表的定义的最后。
-* 按照字母顺序安排定义，`ON DELETE`排在`ON UPDATE`前。
+  * 按照字母顺序安排定义，''%%ON DELETE%%''排在''%%ON UPDATE%%''前。
-* 有道理的话，把所有相关的语句对齐。比如，把所有`NOT NULL`定义对齐到同一列。虽然这样的做法有些慢，但是能提高可读性。
+  * 有道理的话，把所有相关的语句对齐。比如，把所有''%%NOT NULL%%''定义对齐到同一列。虽然这样的做法有些慢，但是能提高可读性。
-##### Validation 校验
+== Validation 校验 ==
-* 用`LIKE`和`SIMILAR TO`约束来保证格式已知字符串的数据完整性。
+  * 用''%%LIKE%%''和''%%SIMILAR TO%%''约束来保证格式已知字符串的数据完整性。
-* 当数字的值的范围可以确定时，用`CHECK()`来防止错误的值进入数据库或被错误地转换。大部分情况下至少要确认值要大于零。
+  * 当数字的值的范围可以确定时，用''%%CHECK()%%''来防止错误的值进入数据库或被错误地转换。大部分情况下至少要确认值要大于零。
-* `CHECK()`约束应该在单独的语句中以便debug。
+  * ''%%CHECK()%%''约束应该在单独的语句中以便debug。
-##### Example
+== Example ==
-```sql
+<code sql>
 CREATE TABLE staff (
     PRIMARY KEY (staff_num),
@@ Line 336: / Line 321: @@
                    CHECK(pens_in_drawer >= 1 AND pens_in_drawer < 100)
 );
-```
+</code>
+==== Design to avoid ====
-### Design to avoid
-* 面向对象设计思想并不适用于关系型数据库——避免这个陷阱。
-* 将值存入一列并将单位存在另一列。列的定义应该让自己的单位不言自明以避免在应用内进行合并。使用`CHECK()`来保证数据库中的数据是合法的。
-* [EAV (Entity Attribute Value)][eav]表——用特殊的产品来处理无模式数据。
-* 因为某些原因（如为了归档、为了划分跨国公司的区域）将能合并在一起的表分开。这样的设计导致以后必须使用`UNION`操作而不能直接查询一个表。
+  * 面向对象设计思想并不适用于关系型数据库——避免这个陷阱。
+  * 将值存入一列并将单位存在另一列。列的定义应该让自己的单位不言自明以避免在应用内进行合并。使用''%%CHECK()%%''来保证数据库中的数据是合法的。
+  * [[https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model|EAV (Entity Attribute Value)]]表——用特殊的产品来处理无模式数据。
+  * 因为某些原因（如为了归档、为了划分跨国公司的区域）将能合并在一起的表分开。这样的设计导致以后必须使用''%%UNION%%''操作而不能直接查询一个表。
-## 附录
+===== 附录 =====
-### 保留字参考
+==== 保留字参考 ====
 下表包含了ANSI SQL (92, 99 和 2003)、MySQL 3到5.x、PostgreSQL 8.1、MS SQL Server 2000、MS ODBC和Oracle 10.2中的关键字。
-```sql
+<code sql>
 A
 ABORT
@@ Line 1178: / Line 1161: @@
 ZEROFILL
 ZONE
-```
+</code>
-[simon]: https://www.simonholywell.com/?utm_source=sqlstyle.guide&utm_medium=link&utm_campaign=md-document
-    "SimonHolywell.com"
-[issue]: https://github.com/treffynnon/sqlstyle.guide/issues
-    "SQL style guide issues on GitHub"
-[fork]: https://github.com/treffynnon/sqlstyle.guide/fork
-    "Fork SQL style guide on GitHub"
-[pull]: https://github.com/treffynnon/sqlstyle.guide/pulls/
-    "SQL style guide pull requests on GitHub"
-[celko]: https://www.amazon.com/gp/product/0120887975/ref=as_li_ss_tl?ie=UTF8&linkCode=ll1&tag=treffynnon-20&linkId=9c88eac8cd420e979675c815771313d5
-    "Joe Celko's SQL Programming Style (The Morgan Kaufmann Series in Data Management Systems)"
-[dl-md]: https://raw.githubusercontent.com/treffynnon/sqlstyle.guide/gh-pages/_includes/sqlstyle.guide.zh.md
-    "Download the guide in Markdown format"
-[iso-8601]: https://en.wikipedia.org/wiki/ISO_8601
-    "Wikipedia: ISO 8601"
-[rivers]: http://practicaltypography.com/one-space-between-sentences.html
-    "Practical Typography: one space between sentences"
-[reserved-keywords]: #reserved-keyword-reference
-    "Reserved keyword reference"
-[eav]: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
-    "Wikipedia: Entity–attribute–value model"
-[sqlstyleguide]: http://www.sqlstyle.guide
-    "SQL style guide by Simon Holywell"
-[licence-zh]: https://creativecommons.org/licenses/by-sa/4.0/deed.zh
-    "署名-相同方式共享 4.0 国际"

知识库｜湖南麓川信息科技有限公司

User Tools

Site Tools

Differences

Page Tools