以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
大部分情況，這些字段都有必要，除非不需要保留已删除資料的不需要删除辨別，而這種情況，基本在項目開始時分辨不出需要邏輯删除還是實體删除。
建立時間、修改時間、建立人、修改人沒必要解釋
十、狀态值
狀态值，盡量不使用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'
防止字元串比較時出現隐式轉換。
總結、好的設計會提高性能，提升便利
在保證性能的基礎上，友善開發、易于運維、易于交接。
以上原則不是鐵律，如果有的原則導緻性能急劇下降，使用很不便利，完全可以無視原則，具體情況具體分析。世界上沒有放之四海皆準的規則。
作者：
公敵依波拉 一劍破萬法
出處：
https://www.cnblogs.com/klarck/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。