以前經常能夠看到，數據庫範式，現在說數據庫三大(dà)範式的少了。

三大(dà)範式我(wǒ)(wǒ)以前也很嚴格的弄過，但是後來發現，還是靈活好啊，爲什麽，業務變動太快了啊，按照範式來，結構變更頂不住。

下(xià)面我(wǒ)(wǒ)就說一(yī)說設計數據庫表要注意的一(yī)些地方吧。我(wǒ)(wǒ)不是DBA，隻是Java後端開(kāi)發，以下(xià)是根據我(wǒ)(wǒ)的個人經驗所得，至于能不能體(tǐ)會，看個人了。

外(wài)鍵、觸發器

外(wài)鍵、觸發器不要有。

有了外(wài)鍵、觸發器，你會發現： 寫代碼不方便。 訂正數據不方便。 遷移數據也麻煩。 總之，你要是堅持用，後續的坑等着你。

自增id

數據庫表，一(yī)定要有id，而且要用自增id！

有些人喜歡用自定義的，用UUID或者其他七七八八的id，如果在架構設計，代碼比較好的情況下(xià)，不會出啥大(dà)問題，但是一(yī)旦代碼寫的不行，極有可能就造成id重複之類的問題。

自增id另外(wài)還有一(yī)個好處，就是在數據遷移的時候，分(fēn)頁查詢通過id來進行分(fēn)頁，速度會比傳統分(fēn)頁快很多。

創建時間&修改時間

創建時間和修改時間這兩個字段，每個表都要有！ 注意，一(yī)定要用數據的時間戳，自動生(shēng)成。不要通過代碼去(qù)操作這兩個字段。

有了這兩個字段。你可以追溯到數據的時間點，創建和修改的時間點。極大(dà)方便你在某些情況下(xià)的排查數據問題。

創建人&修改人

建議每個表也有這兩個字段。

還是和前面一(yī)個原因，出問題的時候可以追溯起因，否則遇上日志(zhì)過久無法查看或者其他原因出現未知(zhī)數據，都不知(zhī)道數據怎麽來的，需要花非常大(dà)的代價查看日志(zhì)、代碼等。

大(dà)文本字段

一(yī)列需要占很大(dà)空間的字段，一(yī)定要單獨拎出來，不要和常用信息放(fàng)一(yī)張表。

舉個例子： 文章的信息和文章的内容，這一(yī)定要分(fēn)成兩個表。否則會給你的文章性能帶來極大(dà)的挑戰。因爲很多情況下(xià)，查看文章列表，根本不需要查看到文章的内容。

表與表的關聯

表與表之間的信息,用id進行關聯，盡量不要有冗餘的信息數據，否則你需要更新同一(yī)份信息的時候，需要更新多個地方。

但是在某些情況下(xià)，你确認信息不會經常變動，且該信息确實在兩個表中(zhōng)都有會比較好，那麽，放(fàng)心的去(qù)冗餘吧。但是注意，數據的更新用上事務。

單庫單表單系統寫原則

這個原則我(wǒ)(wǒ)自己想出來的，也就是說，數據庫中(zhōng)的一(yī)張表，隻能有一(yī)個系統對其進行寫操作。 其他的系統如果想寫這張表，那麽經過調用這個系統的接口進行操作。

如果有多個系統寫同一(yī)張表，可能帶來的問題會很多。首先就是數據并發問題，其次就是事務問題，還有就是表結構變更問題，數據來源追溯問題等等。

如果誰有一(yī)張表數據想用多個系統來進行寫，那肯定是想把團隊拖垮。時間越久，債務越多！

總結

數據庫設計，标準其實是在變的，不變的隻是思想。

業務場景不同，實際需求不一(yī)樣，不會存在一(yī)樣的設計，但是通用的思想都是一(yī)樣的，爲業務服務，爲未來服務，方便維護，方便擴展。

這條路很長，隻能慢(màn)慢(màn)在路上體(tǐ)會了。