为什么别人总说你的SQL代码写得臭？

点击蓝色“有关SQL”关注我哟

加个“星标”，天天与10000人一起快乐成长

感谢那些曾经说我代码臭的小伙伴们，没有你们的鞭策，我不会有觉悟提高自己的 SQL 水平。

其实， 说 SQL 代码臭，最主要的原因，还是没有和团队的风格保持一致。当然，烂风格就不要保持了，要坚决打破它！

说几个烂团队经常采用的 SQL 代码风格：

表名

我见过很多这样的表名：

• XiaoshouRibaoBiao

• SalesRiBao

• 销售报表

• XS_BB

请问，这样的表名，你能记得住几天？

就拿 XiaoshouRibaoBiao 来讲，原意是【销售日报表】，那么【销售周报表】，【销售月报表】，我猜莫非是：

• XiaoshouZhoubaoBiao

• XiaoshouYuebaoBiao

• ……

我想正经团队采用的格式大家都猜到了：

• T_SALES_DAILY_REPORT

• T_SALES_WEEKLY_REPORT

• ……

这里至少有 3 条规则，要定下：

• 表名全大写，方便迁移数据库，也方便前端ORM适配

• 分隔符要用下划线【_】

• 英文命名，这点英文能力应该是所有程序猿基本功

字段名

除了和表名有相同的搞笑命名外，最致命的字段名是使用 SQL 保留字：

• DATE

• TOP

• YEAR

• ……

这部分初学者都该吃过亏。莫名奇妙的报错，想破头，语法都没错，逻辑都没错，字段名冲突了。

在团队里，字段命名，必须有严格的业务意义：

• SALES_UNIT

• SALES_AMOUNT

• PRODUCTION_UNIT

• PRODUCTION_AMOUNT

• SALES_PERSON

• SALES_CUSTOMER

• CREATE_DATE

• UPDATE_DATE

• CREATE_BY

• UPDATE_BY

• ……

UNIT 是产品件（SKU)单位，AMOUNT 是数量单位。

销售和生产，同样都有产品件单位和数量单位，那么SALES_,PRODUCTION_前缀，就必须加上。

每个表，都有4个特殊字段，CREATE_DATE/BY, UPDATE_DATE/BY. 这四个字段有意义，前面分享过：

为什么要在每张表中加 CreateDate 和 UpdateDate ， 亮三点！

这里还有细节，CREATE_DATE 还是 CREATED_DATE，以免最测试的时候，要多写测试用例。

索引

有些团队很奇怪（那种不建索引的就不提了），索引都是 idx 开头，甚至和表名起的一样:

• T_SALES_REPORT_INDEX

• IDX_SALES_REPORT

第一条索引，我都差点认为是个表；而第二种索引，乍看我并不知道，用了哪个字段，做的是不是不可重复索引。

常规做法，可以这样：

• IDX_UNQ_SALES_REPORT

• IDX_CUST_PROD_SALES_REPORT

第一种写法，至少表现出是索引对象，而不是表对象；第二种写法，让人一目了然，采用了 CUST(Customer 客户) 和 PROD(Product 产品) 作为索引，而且没有 UNQ(Unique唯一)的限定，那么这个索引，可能是允许有重复值的。

其他对象

看到这里，大家都猜出来，每类数据库对象命名，都有些约定俗成：

• 用短语/缩减字符，作为命名前缀: T, V, SP, FN, IDX

• 大小写统一

• 连字符 [_] 分割词语

这些命名规范，虽然是小事，但每天都要看上万行代码，不想让她们看起来赏心悦目一些吗？

以上的灵感，还是来自于这本好书《数据库高效优化》

--完--

往期精彩：

本号精华合集（三）

如何写好 5000 行的 SQL 代码

如何提高阅读 SQL 源代码的快感

我在面试数据库工程师候选人时，常问的一些题

零基础 SQL 数据库小白，从入门到精通的学习路线与书单