为什么别人总说你的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 大小写统一 连字符 [_] 分割词语
这些命名规范,虽然是小事,但每天都要看上万行代码,不想让她们看起来赏心悦目一些吗?
以上的灵感,还是来自于这本好书《数据库高效优化》
往期精彩: