萬能數據庫設計方法探索

近日負責公司統一用戶中心的數據庫表結構設計，在工作過程中，誕生了一些另類的想法，特分享出來，期待大家拍磚。

思想的演化過程如下。

第一階段：

將企業、機構、家庭等實體抽象為“組織”，Organization，簡稱 “O”，允許多級組織，通過parentId關聯；

將部門等組織下屬分支實體抽象為“部門”，Department，簡稱“D”，允許多級部門，通過parentId關聯；

將自然人實體抽象為“自然人”，Human，簡稱“H”；

抽象出“賬戶”，Account，簡稱“A”；

抽象出“角色”，Role，簡稱“R”。

每一個組織允許擁有多個部門；每一個組織允許擁有多個自然人；每一個部門允許擁有多個自然人。

每一個組織、部門、自然人，都允許擁有多個賬戶。

賬戶可以共享多個角色。

第一階段E-R關系如圖

這是一個非常簡單清晰的模型。

遺憾，真實世界不會如此簡單。

第二階段：

通過對產品業務的深入了解，需求變更為：

一個組織擁有多個部門，但同時一個部門可以從屬于多個組織。（例：兩個獨立經營的連鎖藥店，共享同一個倉儲部門。）

一個部門擁有多個自然人，但一個自然人可以從屬于多個部門。（例：一個公司的總經理，兼職多個重要部門的部門經理。）

一個組織擁有多個自然人，但一個自然人可以從屬于多個組織。（例：一個醫生，可以多點執業。）

第二階段E-R關系如圖

現在還算是正常情況。

第三階段：

新增一個簡單的功能——郵政收貨地址。

這是一個簡單功能，但此次復雜之處在于：業務上，到底是“組織擁有收貨地址？部門擁有收貨地址？自然人擁有收貨地址？還是賬戶擁有收貨地址？各實體與收貨地址，是一對一，還是一對多的關系？”這些問題，產品無法確定未來的功能擴展方向，只能回答“都有可能”。哈哈。。。

按照常規方法設計，為組織、部門、自然人、賬戶與收貨地址之間，兩兩添加多對多關系表。關系表的數量開始膨脹，如同一個果園里，雜草數量比果蔬的數量都要多。。。

為了減少雜草數量，設計了一種抽象雜草：

添加實體（組織、部門、自然人、賬戶）與郵政地址的關系，由實體枚舉code與實體id兩個值，決定真實實體；由郵政收貨地址Id，決定收貨地址。

例如：

實體枚舉code O, 實體id 1，郵政收貨地址id 10，表示：id為1的某個組織，擁有id為10的某個收貨地址。

實體枚舉code H, 實體id 2，郵政收貨地址id 20，表示：id為2的某個自然人，擁有id為20的某個收貨地址。

實體枚舉code A, 實體id 3，郵政收貨地址id 30，表示：id為3的某個賬戶，擁有id為30的某個收貨地址。

第三階段E-R關系如圖

第四階段：

此時公司高層加入需求討論，

A、要求對數據的控制顆粒度應該達到單條數據，并且可能要根據數據與周邊任意實體的關系，進行權限控制，但是具體需求不定，要求做最大彈性設計。

B、追加資質管理、效期管理等功能，業務同樣不知道未來的擴展方向在哪里，要求做最大彈性設計。

于是，抽象雜草的數量也開始膨脹起來。

針對需求A，設計了OneId表，將所有實體的Id在表中備份，未來一旦進行數據行級權限控制，通過OneId表進行關系擴展。

而為了讓抽象雜草的數量不膨脹，設計了萬用關系表，設計如下：

舉例

上述數據，描述了

“Id為1的某個組織，擁有id為10、11的兩個自然人”；

“Id為10的某個自然人，擁有id為100、101的兩個賬戶”。

任何復雜的/未定的多對多關系，都可以用此萬用關系表進行描述。

整個數據庫設計最終版變化為：

注意：無論未來業務如何擴展，關系如何變化，僅需要擴展新的實體即可，不用再考慮與其他實體的關系，對歷史設計不會產生任何沖擊。

這是一種背離了所有現行數據庫設計范式，簡單萬能的數據庫設計方法，Universal DB Design Method，UDDM，簡稱猶大方法吧，感覺很貼切。

對上述設計方法，我的團隊內部已沒有足夠的能力去評判正誤，期待大家踴躍拍磚、共同探索。