你的SQL寫的真垃ji！
感謝那些曾經(jīng)說我代碼臭的小伙伴們，沒有你們的鞭策，我不會有覺悟提高自己的 SQL 水平。
其實， 說 SQL 代碼臭，最主要的原因，還是沒有和團隊的風格保持一致。當然，爛風格就不要保持了，要堅決打破它！
說幾個爛團隊經(jīng)常采用的 SQL 代碼風格：
表名
我見過很多這樣的表名：
XiaoshouRibaoBiao SalesRiBao 銷售報表 XS_BB
請問，這樣的表名，你能記得住幾天？
就拿 XiaoshouRibaoBiao 來講，原意是【銷售日報表】，那么【銷售周報表】，【銷售月報表】，我猜莫非是：
XiaoshouZhoubaoBiao XiaoshouYuebaoBiao ……
我想正經(jīng)團隊采用的格式大家都猜到了：
T_SALES_DAILY_REPORT T_SALES_WEEKLY_REPORT ……
這里至少有 3 條規(guī)則，要定下：
表名全大寫，方便遷移數(shù)據(jù)庫，也方便前端ORM適配 分隔符要用下劃線【_】 英文命名，這點英文能力應該是所有程序猿基本功
字段名
除了和表名有相同的搞笑命名外，最致命的字段名是使用 SQL 保留字：
DATE TOP YEAR ……
這部分初學者都該吃過虧。莫名奇妙的報錯，想破頭，語法都沒錯，邏輯都沒錯，字段名沖突了。
在團隊里，字段命名，必須有嚴格的業(yè)務(wù)意義：
SALES_UNIT SALES_AMOUNT PRODUCTION_UNIT PRODUCTION_AMOUNT SALES_PERSON SALES_CUSTOMER CREATE_DATE UPDATE_DATE CREATE_BY UPDATE_BY ……
UNIT 是產(chǎn)品件（SKU)單位，AMOUNT 是數(shù)量單位。
銷售和生產(chǎn)，同樣都有產(chǎn)品件單位和數(shù)量單位，那么SALES_,PRODUCTION_前綴，就必須加上。
每個表，都有4個特殊字段，CREATE_DATE/BY, UPDATE_DATE/BY. 這四個字段有意義，前面分享過：
為什么要在每張表中加 CreateDate 和 UpdateDate ， 亮三點！
這里還有細節(jié)，CREATE_DATE 還是 CREATED_DATE，以免最測試的時候，要多寫測試用例。
索引
有些團隊很奇怪（那種不建索引的就不提了），索引都是 idx 開頭，甚至和表名起的一樣:
T_SALES_REPORT_INDEX IDX_SALES_REPORT
第一條索引，我都差點認為是個表；而第二種索引，乍看我并不知道，用了哪個字段，做的是不是不可重復索引。
常規(guī)做法，可以這樣：
IDX_UNQ_SALES_REPORT IDX_CUST_PROD_SALES_REPORT
第一種寫法，至少表現(xiàn)出是索引對象，而不是表對象；第二種寫法，讓人一目了然，采用了 CUST(Customer 客戶) 和 PROD(Product 產(chǎn)品) 作為索引，而且沒有 UNQ(Unique唯一)的限定，那么這個索引，可能是允許有重復值的。
其他對象
看到這里，大家都猜出來，每類數(shù)據(jù)庫對象命名，都有些約定俗成：
用短語/縮減字符，作為命名前綴: T, V, SP, FN, IDX 大小寫統(tǒng)一 連字符 [_] 分割詞語
這些命名規(guī)范，雖然是小事，但每天都要看上萬行代碼，不想讓她們看起來賞心悅目一些嗎？
推薦閱讀
歡迎長按掃碼關(guān)注「數(shù)據(jù)管道」