堅韌的繼承數據庫/模型設計決定

我有Users它可以是TypeS,TypeC或TypeA。我有每種類型的模型來存儲附加信息。現在，在Users表，我應該有堅韌的繼承數據庫/模型設計決定

3空的外鍵字段指定他們是
2場，1與類型的名稱和1與外鍵
哪種類型1字段指定與其他型號的外鍵類型
用戶沒有字段，並依靠檢查反向關係？

我正在使用Django，如果你想提供更精確的答案。

2010-02-13 mpen

Django提供Generic relations作爲contenttypes framework的一部分，它允許您實現類似於＃2選項的功能，而且更加靈活。您可以通過添加以下字段到模型建立通用的關係：

content_type = models.ForeignKey(ContentType) 
object_id = models.PositiveIntegerField() 
content_object = generic.GenericForeignKey('content_type', 'object_id')

這樣你就可以分配的TypeS一個，TypeC，或TypeA到每個所討論的用戶。另外，如果您需要添加TypeX或TypeY，則您已經設置好了，不需要擴展模型。

來源

2010-02-13 22:13:50 flanth

我幾次遇到過這種情況。我的個人偏好是選項1（除非將有20種類型的用戶）。

選項1爲您提供了用於保證數據庫完整性（對三列有約束）的外鍵引用的選項。
選項2這不是實際的外鍵引用。該記錄可能不再存在於類型表中。表連接是不可能的。
選項3甚至比選項2更差，在導航到類型表之前需要解釋該值。
選項4可能，但它有點像尋找你的類型數據。它將允許一個用戶擁有多個類型定義。

來源

2010-02-13 21:46:43 Zyphrax

等等...是4真的很差？難道你不能一次性將所有3種類型連接起來，然後如果數據在那裏，它就在那裏，如果沒有，它不是？ – mpen 2010-02-14 23:07:41

和＃3 ...我將不得不檢查他是什麼類型的用戶。如果沒有首先檢查他是否是TypeC，我不能只開始訪問TypeC數據。其實......我猜想那需要兩個查詢，而不是一個？但即使是1，在我開始加入東西之前，我必須檢查FK是不是空的？ – mpen 2010-02-14 23:11:28

我會使用選項＃1,3可空的外鍵。它允許您使用實際的數據庫外鍵關係，其中選項＃2，＃3和＃4不會。因此，你會得到：

最方便快捷的查找了額外的信息
浪費的磁盤空間最小
編程邏輯來確定哪些類型，它並不複雜（雖然稍更復雜的比起來，如果你有一個「二場」的可能性。）

至於你的問題的第2部分，我想我有一個空的外鍵到另一個表來保存業務特定領域。

編輯：有一個原因考慮選項＃2 ...如果您預期可能的類型數量可能會從3增加到10或100，則選項＃1系統將變得越來越討厭..

來源

2010-02-13 21:48:35

堅韌的繼承數據庫/模型設計決定

回答

相關問題