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

共 1613字,需浏览 4分钟

 ·

2021-01-19 20:42

点击蓝色“有关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 数据库小白,从入门到精通的学习路线与书单









浏览 25
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报