以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'
好處
防止字串比較時出現隱式轉換。
總結、好的設計會提高效能，提升便利
在保證效能的基礎上，方便開發、易於運維、易於交接。
以上原則不是鐵律，如果有的原則導致效能急劇下降，使用很不便利，完全可以無視原則，具體情況具體分析。世界上沒有放之四海皆準的規則。