我有三張表：Books、Sagas 和 Universes。Books 將 idSaga 作為外鍵。Sagas 將 idUniverse 作為外鍵。
它們都是一對多的關系。
一本書可以是一個傳奇的一部分，也是更大宇宙的一部分；例如：指環王和指環團契是LOTR傳奇的第一部，而LOTR在Legendarium宇宙中。
我應該如何稱呼像霍位元人這樣的書？它不是任何傳奇的一部分，而是 Legendarium 宇宙的一部分。
我不想向表 Books 添加一個新欄位（用于外鍵），它看起來像是破壞了規范化。添加一個新表以及書籍和宇宙之間的關系看起來有點過分。
uj5u.com熱心網友回復：
我不想向表 Books 添加一個新欄位（用于外鍵），它看起來像是破壞了規范化。
這正是我會做的。我不確定你所說的“它看起來像破壞了規范化”是什么意思，但對我來說這似乎是理想的，因為 Book -> Universe 關系可能很有用。
例如，假設您有一個新功能，您想計算給定 Universe 中的所有書籍。如果books表中沒有外鍵，則必須在sagas表中查詢與 saga 無關的資訊。
通過排除此外鍵，您將限制您將來使用此關系的選項。
總之，我會去：
Books M:1 Saga
Books M:1 Universe
Saga M:1 Universe
我也同意另一個答案，即在某些情況下，一本書可能存在于多個宇宙中，但是否允許由您決定:)
uj5u.com熱心網友回復：
這打破了某種形式的邏輯，如果提議一本書是“不是的一部分，一個傳奇” -或者兩者圖書和佐賀需要暗示宇宙，但一本書可能意味著不同的宇宙（S）比佐賀它的一部分.
這是如果每本書的部分核心問題是解決一個傳奇，即使只有一本書的佐賀（霍位元人是唯一的書在霍位元人佐賀..目前;-)）。
在基本形式中，正如目前所描述的，這將防止出現此類矛盾的可能性并允許一致地撰寫查詢1，而不管 Saga 中有多少本書。
Books M:1 Saga
Saga M:1 Universe
另一個原因是使用這個模型，每本書中是的一個傳奇，是也適用于首個，佐賀書籍等時尚未成立（也許以后的書還沒有被規劃）。
當然，這可能不夠靈活（閱讀：太簡單）與交叉，例如一些漫畫書，這取決于所需的細化分類..也許并非 Saga 中的所有書籍都共享同一個宇宙。如果這種奇怪的事情是可能的，那么一本書就需要與 Universe 建立非 Saga 關系。
1雖然使用視圖可以相對簡單地處理查詢復雜性，但避免矛盾會增加模型的復雜性。一種方法是要求一本書成為傳奇或宇宙的一部分；不是都。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/376028.html
上一篇：Python：資料庫做while