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

作者：Lenis

来源：有关SQL

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

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

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

表名

我见过很多这样的表名：

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

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

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

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

字段名

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

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

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

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

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

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

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

索引

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

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

常规做法，可以这样：

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

其他对象

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

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

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

--END--

扫码即可加我微信

观看朋友圈，获取最新学习资源

学习更多：
整理了我开始分享学习笔记到现在超过250篇优质文章，涵盖数据分析、爬虫、机器学习等方面，别再说不知道该从哪开始，实战哪里找了
“点赞、留言”就是对我最大的支持！