數據庫設計。繼承

想象一下，您正在開發一個Web應用程序，其中不同的「實體」（具有不同的屬性）發送消息並與來自其他實體的公共消息進行交互。這些實體可能有幾種類型：只是用戶，私人公司，學院......數據庫設計。繼承

設計數據庫我可以想到兩個選項，我認爲會工作，但我不知道哪一個更好，或者如果有是沒有出現在我身上的其他更好的選擇。

選項1：在不同的表中分隔不同的實體。在這種情況下，存儲消息的表應至少有兩列來標識發佈它的實體，id和type。

選項2：使所有實體從父類繼承。因此，存儲消息的表只需要一個指向發佈它的實體的ID的外鍵。這個選項看起來好多了，但問題是我找不到所有實體的通用屬性，所以父表只會有一個id。

您認爲哪個選項更好？有沒有更好的選擇？

PS：對於選項2，是否有必要讓子表具有自己的id或將外鍵定義爲主鍵就足夠了？

謝謝。

來源

2016-07-24 DandyCC

我希望我能正確理解你的問題。
我們有幾個實體，它們發佈消息。我們正在努力尋找優化的設計解決方案來存儲消息。

選項1：在不同的表中分隔不同的實體。在這種情況下，存儲表信息應至少有兩列，以確定發佈它，ID的實體，並鍵入

有至少兩列(id , type)，以確定發佈者是不是一個很好的設計。由於我們試圖用定製解決方案取代發行商的外鍵，副作用將失去數據完整性。考慮一下，如果沒有現有發佈商的ID，那麼會阻止郵件被保存。或者當將要定義一些新的實體類型時。
正確的方法是讓發佈者擁有外鍵，並且最終會在消息表中包含多個可以爲空的外鍵列。這不是讚賞，但更好的解決方案id+type。

選項2：使所有實體從父類繼承。因此，存儲消息的表只需要一個指向的外鍵給發佈它的實體的ID。這個選項看起來好多了，但是問題在於我找不到所有的實體都有共同的屬性，所以父表只會有一個id。

我會選擇這種方法。

我無法找到共同屬性的所有實體

消息發佈的本質是最明顯的共享功能（屬性）。但我認爲有，如姓名，註冊日期，狀態等共享的屬性...

對於選項2，那會是必要的子表有其自己的ID或定義外鍵作爲主鍵會在RDBMS足夠

造型繼承了一個解決方案：
父母的主鍵將子表和內的外鍵和本外鍵必須是子表的主鍵。

來源

2016-07-25 09:58:37

感謝您的回答。選項2對我來說似乎也更好 – DandyCC

隨着NoSQL的到來，這些概念問題現在很容易解決。想象你有一個網絡，就像你說的那樣，你可以在其中保存任何類型的數據（一個與一個人，一組人或一個單一組織有關的網絡信息），現在有一些解決方案。

我將給出一個關於NoSQL數據庫文檔如何解決這個問題的主要例子。您可以在一個集合/表格中解決所有消息。下面是一個例子：

[ 
    { 
     "message": "Test message", 
     "destination": [ 
      { "type": "user", "username": "user1" } 
     ] 
    }, 
    { 
     "message": "Test message", 
     "destination": [ 
      { "type": "org", "username": "company1" }, 
      { "type": "user", "username": "user3" }, 
     ] 
    }, 
]

當然，NoSQL數據庫也可以像關係型數據庫一樣使用id。在前面的示例中，您可以在每條消息上以及每個目標對象列表中放置一個ID。

來源

2016-07-24 22:24:00 Odonno

謝謝，我不知道NoSQL有多強大，但我需要使用MySQL – DandyCC

好吧，我想你必須創建每種類型的目標所需的表和列的確切數目（1爲用戶，1爲組織等）。不是一個靈活的解決方案，但它可以工作。 – Odonno

是的，這正是我必須做的。 – DandyCC

數據庫設計。繼承

回答

相關問題