做爲後端開發如何設計數據庫系列文章(一)設計傳統系統表結構

本篇爲第一篇。講解傳統系統的表結構設計（Java開發）。

講講如何避免數據庫設計的一些坑，方便後期的開發與維護。

之前常常可以看到，數據庫範式，如今說數據庫三大範式的少了。

三大範式我之前也很嚴格的弄過，可是後來發現，仍是靈活好啊，爲何，業務變更太快了啊，按照範式來，結構變動頂不住。

下面我就說一說設計數據庫表要注意的一些地方吧。我不是DBA，只是Java後端開發，如下是根據個人我的經驗所得，至於能不能體會，看我的了。

外鍵、觸發器

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

自增id

數據庫表，必定要有id，並且要用自增id！
有些人喜歡用自定義的，用UUID或者其餘七七八八的id，若是在架構設計，代碼比較好的狀況下，不會出啥大問題，可是一旦代碼寫的不行，極有可能就形成id重複之類的問題。
自增id另外還有一個好處，就是在數據遷移的時候，分頁查詢經過id來進行分頁，速度會比傳統分頁快不少。

建立時間&修改時間

建立時間和修改時間這兩個字段，每一個表都要有！ 注意，必定要用數據的時間戳，自動生成。不要經過代碼去操做這兩個字段。

有了這兩個字段。你能夠追溯到數據的時間點，建立和修改的時間點。極大方便你在某些狀況下的排查數據問題。

建立人&修改人

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

仍是和前面一個緣由，出問題的時候能夠追溯原由，不然趕上日誌太久沒法查看或者其餘緣由出現未知數據，都不知道數據怎麼來的，須要花很是大的代價查看日誌、代碼等。

大文本字段

一列須要佔很大空間的字段，必定要單獨拎出來，不要和經常使用信息放一張表。

舉個例子： 文章的信息和文章的內容，這必定要分紅兩個表。不然會給你的文章性能帶來極大的挑戰。由於不少狀況下，查看文章列表，根本不須要查看到文章的內容。

表與表的關聯

表與表之間的信息,用id進行關聯，儘可能不要有冗餘的信息數據，不然你須要更新同一份信息的時候，須要更新多個地方。

可是在某些狀況下，你確認信息不會常常變更，且該信息確實在兩個表中都有會比較好，那麼，放心的去冗餘吧。可是注意，數據的更新用上事務。

單庫單表單系統寫原則

這個原則我本身想出來的，也就是說，數據庫中的一張表，只能有一個系統對其進行寫操做。 其餘的系統若是想寫這張表，那麼通過調用這個系統的接口進行操做。

若是有多個系統寫同一張表，可能帶來的問題會不少。首先就是數據併發問題，其次就是事務問題，還有就是表結構變動問題，數據來源追溯問題等等。

若是誰有一張表數據想用多個系統來進行寫，那確定是想把團隊拖垮。時間越久，債務越多！

總結

數據庫設計，標準實際上是在變的，不變的只是思想。

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

這條路很長，只能慢慢在路上體會了。