你的SQL写的真垃ji！
感谢那些曾经说我代码臭的小伙伴们，没有你们的鞭策，我不会有觉悟提高自己的 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 大小写统一 连字符 [_] 分割词语
这些命名规范，虽然是小事，但每天都要看上万行代码，不想让她们看起来赏心悦目一些吗？
推荐阅读
欢迎长按扫码关注「数据管道」