數據庫設計：每種實體類型的一組表格或所有實體類型的通用集合

Question

我公司每年組織一次美食節。該節日期間舉辦了許多活動。我的任務是使用CMS（內容管理系統）設計節日網站。

有3種主要類型的實體 - 事件，建立，人員。一個事件有許多參與機構（贊助商，餐館，酒店）和人員（廚師，釀酒廠代表，調酒師）。

每個實體可以有許多類別，許多文檔，照片畫廊和鏈接到其他類型的實體。哪一個更好 - 案例1或案例2（見下文）？

[案件1] - 一組用於每個實體類型的表：

桌事件：事件，eventCategory，eventDocument，eventGallery，event_establishment，event_person

用於建立表：建立，establishmentCategory ，establishmentGallery，establishment_person

桌人：人，personCategory，personDocument，personGallery

personDocument表的示例列：docId，docFilename

請注意，上述各列對於eventDocument和establishmentDocument完全相同。

[情況2] - 爲每個實體類型，類型表和一個通用的一組表的一個表：

表：事件，建立，人，的EntityType，entityCategory，entityDocument，entityGallery，entity_entity

爲entityDocument樣品列：的docId，entityTypeId，docFilename

欣賞任何建議 - 謝謝！

Answer 1

這只是我的看法，但我一直在做這一段時間。

案例1是迄今爲止最容易維護和我的經驗中最推薦的。您可以管理您的實體，並根據您用於編寫網站的語言，您可以談論一些ORM框架的優勢，這些框架將使您的生活再次變得更加輕鬆。

案例2，在SQL數據庫這樣做會導致你的許多問題。你最終會寫很多不必要的代碼來嘗試和檢測類型，確保你做了正確的連接。這將是一場噩夢！我真的無法想到這樣做的好處。

您可能有一個No-SQL數據存儲的案例3。像MongoDB或RavenDB一樣。沒有結構需要擔心。你放入的是你得到的東西，沒有任何翻譯。 （至少使用RavenDB）。對於大規模應用程序，無SQLData存儲的速度要快很多，但它們需要一段時間才能讓您的頭腦正確地使用它們。

我建議你去案例1