数据库设计：每种实体类型的一组表格或所有实体类型的通用集合

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