好的資料庫結構 (database schema) 和壞的資料庫結構在多個方面存在顯著差異，這些差異會直接影響資料庫的效能、可維護性、擴展性和數據完整性。並且當開發系統時，好的資料庫結構可以讓程式容易撰寫及維護，而壞的資料庫結構可能讓程式變得很龐大，並且無法在變更系統需求時還能修改維護。
以上的說法，可能很難以理解，我們用實際的例子來說明。
我們用農民曆上的食物相剋圖來設計資料庫結構，狀況及需求如下 :
(1)當兩個食物一起吃，會造成不適的症狀，例如拉肚子或是中毒。
(2)可以透過解毒物來解除不適的症狀。
我們先抓出物件 : 食物、解毒物、不適的症狀。
因此會有一個食物的資料表單，然後會有解毒物的資料表單，至於這兩個物件是應該兩個資料表單，還是合成一個資料表單，後面再來決定。
不適的症狀也會是一個資料表單，裡面會有兩個食物的欄位，如果症狀用文字表示，有違反正規化的情況，因此不適症狀資料表單中以症狀id來關連到另外一個症狀表，會比較恰當。
最後，特定症狀需要使用特定解毒物，也會形成一個解毒的資料表單。
綜合以上，形成資料表單如下 :
Food（食物）：包含食物id、食物名稱和描述等資料。
Interaction（相剋反應）：包含反應id、兩種食物的id和症狀id。
Symptom（症狀）：包含症狀id、症狀描述。
Antidote（解毒物）：包含解毒物id、名稱和描述等資料。
Solution（解毒表）：包含解毒id、反應id、解毒物id。
經PlantText.com產生ER Diagram如下 :
food : (1, '食物A', 'food A description'), (2, '食物B', 'food B description)
antidote : (1, '解毒物C', 'antidote C description')
interaction : (1, 1, 2, 1)
symptom : (1, '中毒')
solution : (1, 1, 1)
從以上資料看起來，你會發現三件事情 :
symptom : (1, '中毒')
solution : (1, 1, 1)
從以上資料看起來，你會發現三件事情 :
(1) food與antidote兩個結構與性質完全一樣，似乎可以變成一個表單。
(2) 如果三個以上的食物造成中毒，這個表單就無法呈現。
(2) 如果三個以上的食物造成中毒，這個表單就無法呈現。
(3) 如果兩個以上的解毒物可以緩解，這個表單也無法呈現。
前面提到，壞的資料庫結構無法在變更系統需求時還能修改維護，像現在只是把食物從兩個變成三個以上，或是把解毒物從一個變成兩個以上，整個結構就卡住了。
而且這個變更是很正常的，兩種食物一起吃會造成中毒，當然可能三種食物一起吃也會造成中毒。
因此我們就必須更改以上資料表單的結構，把food與antidote變成一個表單，並且食物與解毒物的個數不需要限制，允許一個到無限多個。
它可以追蹤不同物質（食物或解藥）之間的相互作用，以及這些相互作用可能導致的症狀和相應的解決方案。
以下是對每個實體和關係的解釋：
實體 (Entities)
Substance : 代表食物或解藥。每個物質都有唯一的 ID、名稱和描述。
Symptom : 代表可能由物質相互作用引起的症狀。每個症狀都有唯一的 ID 和描述。
Interaction : 代表兩種或多種物質之間的相互作用。每個相互作用都有唯一的 ID，並與可能導致的症狀相關聯。
Solution : 代表解決特定相互作用引起的症狀的方法。每個解決方案都有唯一的 ID，並與相互作用相關聯。
SubstanceInteraction : 一個關聯表 (associative entity)，用於連接 `Substance` 和 `Interaction`。它記錄了哪些物質參與了特定的相互作用。
SubstanceSolution : 另一個關聯表，用於連接 `Substance` 和 `Solution`。它記錄了哪些物質（解藥）可以用於特定的解決方案。
關係 (Relationships)
causes : 一個 `Interaction` 可能導致一個 `Symptom`。
treated_by : 一個 `Interaction` 可以被一個 `Solution` 治療。
SubstanceInteraction : 一個 `Substance` 可以參與多個 `Interaction`。 一個 `Interaction` 可以涉及多個 `Substance`。
SubstanceSolution : 一個 `Substance` 可以用於多個 `Solution`。 一個 `Solution` 可以使用多個 `Substance`。
總結
這個 ER diagram 展示了一個用於管理物質相互作用、症狀和解決方案的資料庫結構。它允許追蹤哪些物質之間的相互作用可能導致哪些症狀，以及可以使用哪些物質（解藥）來解決這些症狀。這種結構對於建立一個關於食物、藥物和其他物質之間相互作用的知識庫非常有用。
以上範例只說明了如何讓資料庫結構可以因應「擴展性」的問題，並且也兼顧到資料庫的「正規化」、「可維護性」、「數據完整性」問題，但是在「效能」上並沒有明顯的優勢。
後續再用更多的範例，來說明好壞資料庫結構對於「效能」方面的影響。
 的差異是什麼?){kind=link}
0 留言