我設計資料庫常用的幾個原則
以MySQL5.7為例，在一個項目中的資料庫schema中建表
〇、建庫
統一字符集和排序規則
規則
庫的默認字符集選擇utf8mb4，表、欄位默認上級
庫的排序規則選擇utf8mb4_general_ci，表、欄位默認上級
好處
統一排序規則，防止不必要的隱式轉換，庫級先指定，表級，欄位級默認上級即可。
一、命名法
如果是大小寫敏感的資料庫【MySQL】就用蛇形命名法【小寫+下劃線】
如果是大小寫不敏感的資料庫【SQL Server】就用大駝峰式【大小寫】
二、望文生義，自說明
百度百科中，望文生義：漢語成語，意思是指不了解某一詞句的確切涵義或來源緣由，光從字面上去牽強附會，做出不確切的解釋。
規則
在資料庫設計中，表名欄位名一定要用有意義的名詞，即自說明，每一個名詞都是由有意義的英文或者通用英文縮寫組成。鑒別方式：使用百度搜索欄位名中的單詞，可以搜索到，則命名沒問題。
例子
公司可以使用 corporation 或者縮寫corp，不能用gongsi，下圖為搜索縮寫的結果
數量可以使用 quantity 或者縮寫qty，不能用shuliang、numb（糟糕的選擇，單詞意義是麻木的; 失去知覺的; 遲鈍的; 獃滯的）、num。下圖為縮寫搜索的結果
注意：縮寫必須是約定俗成的，是行業通用的，否則寧可欄位過長也不要縮寫。不規範的縮寫會導致表名易用性和可維護性變差。對開發人員和維護人員極其不友好。
好處
使不了解表結構的人，直接看錶名、欄位名就可以知道表、欄位的意義。盡量不查備註，因為查看備註也需要花時間，對開發的編碼流暢性干擾很大。
注意：
1、欄位名要簡短、易於理解、無歧義。
2、雖然已經望文生義、自說明，但是不意味著可以省略備註，每個表和欄位還是有必要加上備註的，防止出現歧義。
三、欄位統一
規則
意義相同的欄位就算在不同表中也要保持欄位名相同、保持類型相同。
所以備註要言簡意賅，如果不同表出現相同欄位，只要全庫搜索備註就能找到相同意義的欄位，這樣就可以維持欄位統一
好處
1、依舊是望文生義，當已經習慣於一個欄位名，該欄位在其他表中出現對開發識別欄位意義有幫助
2、當兩個表的數據相互傳遞時，可以使用相同屬性名反射實現set、get方法，給開發提供便利
3、類型相同防止欄位比較時出現隱式類型轉換
四、模組分組
如果系統設計中劃分了模組，各模組的表名中必須加了相同的模組簡稱前綴
例子
字典表模組中的
計量單位表dict_unit
公司表dict_corp
系統模組中的
用戶表sys_user
角色表sys_role
好處
相同模組的表在工具中查看時是排列在一起的。方便查找相關表。
五、主鍵名
主鍵id不能統一命名為id，有要加上表資訊，即用戶表user主鍵user_id
規則
不要使用統一id當主鍵名，要有修飾詞
例子
用戶屬於某公司，即用戶表中需要存儲公司表的主鍵作為外鍵【即使不建立外鍵】
用戶表使用user，公司表使用corp
如果在公司表中主鍵id使用id，但在user表中主鍵id也是id，必然user表的外鍵公司id 應該是corp_id，這樣會導致一個結果當user表和corp表聯結時，
聯結條件必須是user.corp_id = corp.id
如果聯結的表過多時表名使用別名a,b,u,c時極其容易寫錯，還不容易排查錯誤
而如果user表主鍵定義為user_id，corp表主鍵定義為corp_id，user表中的公司id外鍵也定義為corp_id，
這樣當表聯結時，聯結條件寫為user.corp_id=corp.corp_id，聯結條件一目了然。提高了SQL的可讀性，節省了閱讀SQL時表聯結鍵的確認時間。
好處
節省開發時間，就算一次節省半秒，上千次之後也會節省十分鐘，作為一個項目經理或dba，就算你做不到給開發減輕工作量，也不能拖後腿吧。
符合欄位統一原則。
六、盡量not null
規則
在設計欄位時盡量使用not null不可空。
數字類型默認0，字元串類型默認”零長度的字元串。
日期類型如果可以默認當前時間。
我知道作為開發人員嫌不可空麻煩，但是實際上可以在實體的getter方法中改寫
數字可以return userId ==null?0:userID;
字元串可以return name ==null?””:name.trim();
日期可以return dt==null?new DateTime();
以上寫法可以保證你的實體在插入時肯定不空，雖然開發寫起來麻煩，但是好處多多。
好處
易於優化，雖然很多開發不以為然，但是你的項目真的需要高性能時你會後悔莫及，而很多項目開始時由於開發不考慮性能導致後期優化很費勁，為什麼不提前把可以做好的做到最好。
節省空間，雖然可能只節省一個bit，但積少成多，好的性能都是一點一點積累出來的。
防止java出現空指針，好多空指針都是由於臟數據引起的。
NULL可能導致計算錯誤。例如concat（a，b），若a是NULL，結果為NULL。
如果時間欄位無法默認時間，完全可以設置為null，不要在心裡就反對null或者反對not null，我們是設計資料庫，不要出現黨*爭。
七、注意varchar
當欄位可以確定長度不超過一定數值時，建議使用char定長字元串類型，但如果整張表已經出現變長欄位，那麼都使用變長欄位即可。
規則
如果可以都使用定長字元串，如果做不到就都使用變長字元串
好處
節省空間
易於優化
速度快，DBMS易於處理
八、範式
盡量符合三範式
規則
欄位不可分割、表有主鍵、數據沒有允余、表間關係明確
好處
範式目的是使結構更合理，消除存儲異常，使數據冗餘盡量小。便於插入、刪除和更新。
範式是給關係型資料庫創立的。對於增刪改查四種操作總體來說性能和易用性最佳。如果你們的表只需要插入和查詢，或者只需要插入和清空，CRUD四種操作不全需要時，完全可以違反範式。具體情況具體分析，沒有必要在心裡就反對範式或者嚴格遵守範式。我們是設計資料庫，不是教條主義，不要出現黨*爭。
九、固定欄位
刪除標誌、創建時間、修改修改、創建人id、修改人id五個欄位為必須欄位。
規則
刪除標誌默認為未刪除的值，
創建時間設置為當前時間，
修改時間設置為數據修改時更新，
創建人設置id默認為0
創建人設置id默認為0
好處
大部分情況，這些欄位都有必要，除非不需要保留已刪除數據的不需要刪除標識，而這種情況，基本在項目開始時分辨不出需要邏輯刪除還是物理刪除。
創建時間、修改時間、創建人、修改人沒必要解釋
十、狀態值
規則
狀態值，盡量不使用0，一般選擇10，20，30，40等，
好處
防止需求突然加中間狀態，原來定義的是0，1，2，3連續的狀態，突然需要在2，3之間加個新狀態，只能使用4，這樣會對開發理解造成障礙，而如果初始就使用10，20，30，40作為狀態，突然需要在20，30之間的新狀態，完全可以使用25，即好理解又符合邏輯。
0對於前端開發不友好。
最後、上線前統一字符集和排序規則
項目上線之前執行以下SQL，會查詢出指定庫下的所有欄位的排序規則和字符集，一定要統一後，再上線
其他老生常談的問題可以自己查找，比如建議使用自增列做主鍵等
select table_name,column_name,character_set_name,collation_name
from information_schema.columns where table_schema = ‘庫名’ and data_type = ‘varchar’
好處
防止字元串比較時出現隱式轉換。
總結、好的設計會提高性能，提升便利
在保證性能的基礎上，方便開發、易於運維、易於交接。
以上原則不是鐵律，如果有的原則導致性能急劇下降，使用很不便利，完全可以無視原則，具體情況具體分析。世界上沒有放之四海皆準的規則。
