SQL进阶 - SQL的编程规范

性能优化是一个很有趣的探索方向，将耗时耗资源的查询优化下来也是一件很有成就感的事情，但既然编程是一种沟通手段，那每一个数据开发者就都有义务保证写出的代码逻辑清晰，具有很好的可读性。

引子

小试牛刀

答案

引言

表的设计

名字及含义

属性和列

SQL规范

注释

缩进

空格

大小写

逗号

通配符

SQL方法

数据库函数

连接

from子句

引子

小试牛刀

下面九个图形分别对应数字1-9

1 2 3 4

5 6 7 8 9

给大家一分钟的时间尝试能否记住并将他们按照奇偶分开默写出来

1、3、5、7、9、2、4、6、8

注意！下滑有答案！想思考一下的谨慎！

如果正在尝试记忆就先不要下滑，下面就是答案。

当然这组数字图形大概率不那么好记

但是如果换一种方式我保证你只用十秒就理解掌握并且记住他了。

答案就在下面。。

-------------- 分割线 ---------------

答案

如图，九宫格对应1-9辅助记忆即可，选择一种已经被大众接受且规范的做法，无疑是良好的开端。

引言

如何改变 能跑起来就行、效率才是一切 这种偏执的观念，认真的思考如何写出任何人看一眼就觉得简单明了的代码，追求使用大多数人所能理解的常识和模式，确立统一的编程风格。

事实上，数据库领域的发展并没有到开始关注编程风格的阶段，SQL作为一种非过程语言，受到的重视也远远不够，对于SQL这门语言也很少有人深入的研究。但随着数据时代的到来，大家逐渐注意到了SQL的强大实力，同时代码也会变得越来越复杂，数据工程师的SQL代码风格也一定会在不久的将来被明确。

表的设计

名字及含义

关系数据库在各类系统中获得广泛支持的最重要的原因，就在于它放弃了地址这一无意义的概念。放弃地址，留下了名称。

对于列、表、索引，以及约束，命名时都请做到名副其实。尽量不要使用A、aa，或者idx_123 这样无意义的符号。特别需要注意的是，如果没有为索引和约束显式地指定名称， Database 就会自动为之分配随机的名称，这也是要注意避免的。

命名时允许的字符有以下3种：

英文字母
阿拉伯数字
下划线 _

除此之外，各个数据库实现中可能还加入了$、#、@等特殊符号，以及汉字这样2字节的文字，但个人认为最好不要使用。因为这样写出的代码可移植性不好，而且容易隐藏Bug。还有，标准 SQL 中规定名称的第一个字符应该是英文字母，这一点我们也应该遵守。

属性和列

使用有意义的列名：

列名应该反映其存储的数据内容，使用清晰、描述性的名称，避免使用含糊或缩写的名称。
遵循一致的命名约定，如使用下划线或驼峰命名法。

使用适当的数据类型：

选择最合适的数据类型来存储数据，以节省空间并确保数据的准确性。例如，使用整数类型存储整数数据，使用日期/时间类型存储日期和时间。
避免过度使用通用数据类型，如使用TEXT存储日期，这会导致性能问题。

使用合适的默认值：

为列设置合适的默认值，以便在插入新记录时提供默认值，或者在未指定值时使用默认值。

SQL规范

注释

注释是编程风格中一个比较有争议的话题。有些人极力主张必须要添加注释，相反也有人认为注释只会使代码的可读性降低，因此努力方向应该是把代码写得不需要注释也能看懂。

不管其他语言怎么样，就SQL而论，最好还是写注释。这样说主要有两个原因：一个是SQL是声明式语言，即使表达同样的处理过程，逻辑仍然比面向过程语言凝练得多；另一个是，SQL 很难进行分步的执行调试。分析代码时主要需要进行桌面调试。

注释的写法主要有以下两种：


-- 单行注释

-- 使用表t1
select * from t1

-- 多行注释

/*
    一大段注释
    使用表t1查询
*/
select * from t1

注释也可以穿插在代码中或者代码后：

select t1.customer_id, t3.name
from(
    select t1.customer_id as customer_id, t3.name as name, t1.date_mouth, sum(t1.quantity * t2.price) as amount
    -- 下面是一次子查询
    from(
        select customer_id, product_id, substr(order_date, 0, 7) as date_mouth, quantity
        from Orders
    )t1 -- 作为底表向后进行左关联
    left join(
        select product_id, price from Product
    )t2 on t1.product_id = t2.product_id
    left join(
        select customer_id, name from Customers
    )t3 on t1.customer_id = t3.customer_id
    group by t1.customer_id, t3.name, t1.date_mouth
    having amount >= 100
)a
having count(1) = 2

缩进

代码难以阅读的原因里，也许排在第一位的是没有进行缩进（排在第二位的是没有对长代码划分模块，所有的都揉在一起）

对于初学者，他们不了解缩进的重要性，写出来的代码每一行都从行首开始。如果是练习用的小的程序，即使不缩进也不至于带来混乱，因此这样也没什么不可以。但是对于专业的工程师来说，如果写代码没有缩进意识就不能容忍了。

下面是好和坏的示例：

-- bad 
select t1.customer_id as customer_id, t3.name as name, t1.date_mouth, sum(t1.quantity * t2.price) as amount
from(
select customer_id, product_id, substr(order_date, 0, 7) as date_mouth, quantity
from Orders
)t1 
left join(
select product_id, price 
from Product
)t2 
on t1.product_id = t2.product_id
left join(
select customer_id, name 
from Customers
)t3 
on t1.customer_id = t3.customer_id
group by t1.customer_id, t3.name, t1.date_mouth
having amount >= 100

-- good

select t1.customer_id as customer_id, 
       t3.name as name, 
       t1.date_mouth,
       sum(t1.quantity * t2.price) as amount
from(
    select customer_id, 
           product_id, 
           substr(order_date, 1, 7) as date_mouth, 
           quantity
    from Orders
    )t1 
    left join(
        select product_id, 
               price 
        from Product
    )t2 on t1.product_id = t2.product_id
    left join(
        select customer_id, 
               name 
        from Customers
    )t3 on t1.customer_id = t3.customer_id
group by t1.customer_id, 
      t3.name, 
      t1.date_mouth
having amount >= 100

在好的示范里，我们首先可以看到，于查询的代码缩进了一层。请牢记这个规则。子查询这个名称的开头是“子”，这就说明它是低一层的逻辑。然后，在SELECT 子句和 GROUP BY 子句中指定多列时，也需要缩进一层。缩进之后，“子句”的代码块就变得很清晰，更方便阅读。如果不想让代码的行数增加得太多，也可以每行写3列或5列，或者根据具体含义汇总多列进行换行。

空格

无论什么编程语言，适当的空格都会让代码变得更美好。这是一种约定俗成的习惯，当然如果不加空格也不会有任何问题。

# bad
select id,substr(order_date,1,7) as date_mouth,quantity
from Orders

# good
select id, substr(order_date, 1, 7) as date_mouth,quantity
from Orders

大小写

这个也是约定俗成的规范，关键字一般全部大写，其他全部小写，如下：

SELECT col_1,
         col. 1_2,
         col_3,
         COUNT (*)
FROM tbI_A
WHERE col_1 = 'a'
        AND col_2 = 
    (SELECT MAX (col 12)
    FROM tbI_B
    WHERE col 3 =100)
GROUP BY  col_1, col_ 2, co1_3 ;

逗号

这个各自有各自的看法，都是对的，分享一种个人习惯的：

select id
      ,name
      ,age
from Orders

通配符

使用通配符 * 会将表的全部列选中，虽然在写法上方便了许多，但结果中也会包含很多不需要的咧，不但会降低代码的可读性，而且不利用需求的变更。

# good
select id, name, age from Orders

# bad
select * from Orders

SQL方法

SQL 是一种有多种方言的语言，各种数据库实现都为我们做了各种扩展（不管是好的还是坏的）。SQL 官方其实已经制定了标准语法，但是并没能做出多少推动统一的努力。关于这一点，也有一些历史原因。过去的标准SQL 很弱，并没有达到实用的程度，很多数据库厂商不得不自己扩展标准SQL中没有的功能。但是，近年标准SQL 越来越完善，也越来越实用了。如果还继续使用各种数据库的方言进行编程，就会出现很难在 PostgreSQL、Oracle、SQL Server、MySQL 这样的DBMS之间移植代码的情况，而且开发者换到不熟悉的 DBMS 后会很不习惯新的编程环境。这些问题只需要稍微注意一下就可以避免，所以大家还是在日常开发中养成使用标准语法的习惯吧。

数据库函数

很多依赖数据库实现的函数都是转换函数或字符串处理函数。不要使用这些函数：

DECODE（Oracle）
IF（MySQL）
NVL（Oracle）
STUEF（SQLServer）

可以使用 CASE 表达式或者 COALESCE、NULLIF 等标准函数代替它们。此外，像 SIGN或 ABS、REPLACE 这些，虽然标准 SQL没有定义它们，但是几乎所有的数据库都实现了它们，所以使用一下也没关系。让人头疼的是标准SQL中有定义，但是各数据库实现情况不同的功能。例如日期函数 EXTRACT，以及用于字符串连接的运算符“||”或者POSITION 函数。这些函数的使用频率都很高，但是请记住，使用它们会导致代码的可移植性变差。

连接

在SQL 的语法中，依赖数据库实现最严重的是连接语句。

标准SQL 中允许省略关键字OUTER，但是这个关键字便于我们理解它是外连接而非内连接，所以还是写上吧。

SELECT *
FROM FOO F INNER JOIN Bar B
ON F.state = B.state
WHERE F.city='东京；

from子句

优先从from开始写你的SQL吧 ---- 如果他很大的话

原是 SELECT 子句是SQL 语句中最后执行的部分，写的时候根本没有必要太在意。

SQL 中各部分的执行顺序是：FROM - WHERE - GROUP BY - HAVING - SELECT（-ORDER BY）。严格地说，ORDER BY并不是SQL 语句的一部分，因此可以排除在外。这样一来，SELECT 就是最后才被执行的部分了。

因此，如果需要写很复杂的SQL语句，可以考虑按照执行顺序从 FROM 子句开始写，这样添加逻辑时更加自然。即使不知道在 SELECT 子句里写什么，也肯定知道应该在FROM 子句中写些什么（如果不知道，那么说明表的结构还没有确定，因此应该先完成表的设计，然后再考虑 SQL 语句）。

最后的最后，还是那句话，既然编程是一种沟通手段，那每一个数据开发者就都有义务保证写出的代码逻辑清晰，具有很好的可读性。

--------------

2023.10.07