這是學習筆記的第 1740 篇文章
如果你花了一些時間和精力來對SQL審核做一些改進，對於審核的規則和定義已經爐火純青，裡面肯定包含了很多的細節，也包含了很多的技巧，一條SQL語句我們可以給出20條甚至更多的建議，從技術上來說是成功的，但是從業務的使用來說，可能是一種不大友好的方式。
第一，業務還不大瞭解審核的建議，有些術語或者描述可能看得不是很明白和理解 。
第二，對於使用者來說，定製的邏輯和細節太多，導致給出的建議太多，無從下手。
第三，很多建議可能因為現實情況沒法一一改正，但是對於一些硬性要求來說，需要改正，這是自助審核的意義所在。
而對於開發者來說，定製的規則和邏輯太多，導致定製的難度極高。
所以我們對於審核規則可以做到一些定製，這個定製就意味著，從審核工具返回時就約定一個code，通過code來做應用後端做審核規則的定製和管理，在這個地方，我們設置了三個層面，必須改進，潛在問題和建議改進，必須改進就是硬性的要求，比如表要有主鍵，字符集，大小寫等等，這些是沒商量的，違反了就要更正，潛在問題就是哪些看起來不直接違法規範，但是使用中會有一些潛在問題，比如使用了enum類型，建議使用tinyint，比如使用了timestamp，則提示timestamp的範圍可能會比較受限，建議再斟酌下，而建議改進，則是哪些滿足基本規範和標準的前提下，建議業務同學改進的一種方式，比如字段的註釋，比如我們幾乎沒法要求每個同學都對字段有一個標註。
所以我們從後端把規則都沉澱出來，做成元數據管理起來，我們可以改變規則的類別，比如初期的時候，大家違反的“必須改進”類問題多一些，改進之後，我們就可以適當的調整這些規則的類別，反向來促進應用的使用習慣。
這個時候你做完之後會發現，原來看起來比較鬆散的規則一下子梳理整齊了。
比如有20個建議，可能必須要改正的建議有3個，那麼這3個就是重中之重，可能建議的改進有10個，我們可以逐步的完善。
這樣就帶來了第二個問題，怎麼讓應用對自己的SQL有一個更直觀的認識呢。我們可以考慮打分機制。
打分其實是可視化的一種方式，通過分數能夠直觀的看到一個結果的好壞程度。通過分數有幾個意思，一個是對結果的可視化，另外一個則是激勵機制。如果一個人看到分數很低，必然會有改進的慾望。
打分機制是在審核規則基本穩定的情況下需要考慮的，對此我設置瞭如下的積分規則。
1.分為“必須改進”，“潛在問題”，“建議改進”三類，權重值分別為10,5,2
2.三種類型的權重值分數比例為40,30,30
3.“必須改進”類型個數如果超過3個，則直接扣除40分
4.“潛在問題”類型個數如果超過5個，則直接扣除30分
5.“建議改進”類型個數如果超過8個則，直接扣除30分
6. 如果為滿分100，則扣除1分， 提示“滿分會怕你驕傲，繼續保持”
7. 如果分數低於50，最低置為50
我們看一個基本的小例子，可以看到給了4個建議，其中一個建議是比較重要的，另外的改進建議則可以根據實際情況來考慮。
閱讀更多 楊建榮的學習筆記 的文章
