何時爲兩種略有不同的信息使用單獨的SQL數據庫表？

我需要一段時間讓我困惑的SQL決策的幫助。何時爲兩種略有不同的信息使用單獨的SQL數據庫表？

我試圖製作一個小故事網站，用戶可以在這裏寫他們自己的故事，並可以瀏覽彼此等。我還收藏了一些偉大的作家從過去寫的經典短篇小說集。我很困惑我是否應該將這兩種類型的故事存儲在同一個數據庫表中。

我想在一定程度上保持兩種類型的故事（經典作者/用戶）不同，因爲您應該能夠搜索網站並從結果中篩選出用戶故事。但是我不能只在表中有一個單獨的數據庫行來表示它，即一個布爾CLASSIC，因爲使用經典的短庫存，其他幾行也會不同 - 沒有用戶，日期是YYYY（即1869年），而不是用戶提交時的完整日期時間。

然而，我不能把它們放在單獨的表中。當大多數屬性相同時，我是否應該爲短篇故事確實有兩個不同的數據庫表？目前，我正在將NULL填充到用戶行中以獲得經典短篇故事，並且我的篩選搜索具有僅通過經典的搜索選項，該經典從數據庫中選擇用戶爲NULL的位置。這似乎打破了性能，但是當你搜索一個巨大的潛在數百萬用戶故事數據庫時，僅僅是爲了找到幾千個經典故事。

請注意，還有其他表格，如故事標籤，鏈接到短故事表。

所以我基本上問你的SQL專家 - 是否有足夠的理由將兩種類型的信息分離到不同的表中？我目前在開發中使用SQLite，但稍後會切換到MySQL或PostgreSQL。

來源

2013-10-21 Laurence

總之，你有一個層次結構，你需要看看如何把它變成物理模型。可能[這個問題]（http://stackoverflow.com/questions/8685621/what-is-the-best-database-schema-to-support-values-that-are-only-appropriate-to/9460541#9460541）可能有幫助，或者[這個簡化的]（http://stackoverflow.com/questions/19430204/database-design-structure/19430750#19430750）。 –

我可能會用「父子」表結構，在那裏你有匹配的跨表的主鍵，像去：

Stories: StoryId (PK), StoryType (U or C), StoryText, etc. (all of the shared stuff) 
UserStories: StoryId (PK and FK), UserId, etc. 
ClassicStories: StoryId (PK and FK), AuthorName, etc.

然後，如果你願意，你可以圍繞它們構建兩種觀點：

V_UserStories: StoryId, StoryText, UserId, etc. 
V_ClassicStories: StoryId, StoryText, AuthorName, etc.

採用這種設置，你不浪費任何列，你保持共同的東西在一起，同時仍保持兩種類型的故事，如果你需要他們很容易在邏輯上分開。

來源

2013-10-21 19:54:25

在這種情況下，'StoryType'專欄不是技術上需要的 - 如果您內心連接UserStories並獲取記錄，那麼這是一個用戶故事，如果您對ClassicStories進行內部連接並獲得記錄，那麼這是一個經典故事。爲了方便起見，StoryType專欄就在那裏。 –

+1！很高興聽到人們推薦這樣的設計方法！此外，您可以將「標籤」表與「故事」關聯起來，以實現常見功能，同時使「共享」表僅指向「用戶存檔」，原因顯而易見。我可以添加更多，但我已經寫了一篇關於IS-A關係的文章（http://www.geomagas.gr/index.php/is-a-relations-in-relational-databases/）前。 – geomagas

謝謝大家，我會選擇這個設計。 Mosty Mostacho似乎是回答這些類型問題的專家，所有這些答案都使我對整個問題更加清楚。一張普通功能表最好。 – Laurence

爲了做出這樣的決定，你必須考慮如果你想插入你的表的字段只爲你的表而沒有別的。例如

故事和故事的類型，如果一個故事可以有幾種類型的故事和/或幾種故事的類型，那麼是的，你必須製作一個特定的表類歷史，但如果只有一種類型的故事涉及一個故事，然後你直接插入故事表的類型信息（名稱，描述等）。

來源

2013-10-21 20:02:24 Victor

何時爲兩種略有不同的信息使用單獨的SQL數據庫表？

回答

相關問題