最近合作搞項目，發(fā)現(xiàn)了很多問題。特別的，數(shù)據(jù)庫層面上的問題更為致命。記錄一下，希望后面看到博客的同學(xué)們注意。
注意：以下觀點只用于一般情況下的單體、微服務(wù)，不保證適用所有場景。

一、ID問題

ID名稱問題

如下圖：有的同學(xué)喜歡，xx_id，這就很讓人迷惑。因為，一般我們使用邏輯外鍵的時候才會這么寫，而實際開發(fā)的時候，表的id，就固定為id字段，如圖二。

ID自增長、映射類型

默認(rèn)id自增長、映射為JAVA種的Integer

邏輯外鍵

• 一張表的邏輯外鍵最好限制為一個，過多的邏輯外鍵，盡量額外建表維護。

二、字符

長度

• 最好使用四種默認(rèn)長度64、255、1024、2048，使用別的長度，要有明確的要求。
• 超過2048麻煩額外建表。

適用范圍

• 盡量不要用字符存枚舉、類型、狀態(tài)、ID

三、時間

• 不知道選的，默認(rèn)選DATATIME
• 語句-默認(rèn)當(dāng)前時間： DEFAULT CURRENT_TIMESTAMP
• 語句-更新字段后更新時間：ON UPDATE CURRENT_TIMESTAMP
• 沒有必要，不要存時間戳

四、整型

• 枚舉字段使用默認(rèn)：tinyint
• 不知道的整型默認(rèn)：int
• 不要設(shè)定初始默認(rèn)值，讓應(yīng)用去控制

五、字段

• 超過2048字符長度的，盡量使用額外一張表
• 如果有大字符、大內(nèi)容需要存，使用文件服務(wù)。
• 如果不想建文件服務(wù)，就存文件名，然后用本地文件系統(tǒng)。一定不要存文件到數(shù)據(jù)庫。
• 不要存模糊的字段，不要使用默認(rèn)值（時間除外），因為后期會變成一個坑。
• 不要設(shè)計備注、冗余字段，要改的表，讓它改，冗余設(shè)計和bug一樣恐怖

六、數(shù)據(jù)庫的三大范式

如果誰設(shè)計的數(shù)據(jù)庫不滿足的，讓它改！！！

不滿足范式的設(shè)計，后期大概率要出問題。

七、關(guān)系

表間關(guān)系

• 一對多、多對一的情況，可以使用邏輯外鍵
• 多對多的情況，一定要建中間表，而且命名要有明顯的辨識度例如：tm_user_role。tm就是中間表
• 優(yōu)先使用分組表，而不是分組字段。

行關(guān)系

設(shè)計二叉樹行時，例如：每個行都有id、parent_id，其中parent_id是id的邏輯外鍵。

• 保證數(shù)據(jù)總量的有窮性、最大值不會影響性能。
• 可以的話，設(shè)計類似：00112233一樣的字段作為code或字段level，進行快速識別。例如(第1-2、3-4、5-6行)、level代表樹的高度。
• 不要使用二叉樹分組，新建一個分組表。

八、字段切割

• 一張表最多20個字段，超過需要切割。
• 實際上最多15個就夠了，超過12個字段，就應(yīng)該仔細(xì)看是不是有問題。

最后，以上就是我的個人經(jīng)驗，如有想法，請留言，感謝。