数据库设计：每个实体类型的一组表或所有实体类型的通用集答案

【问题标题】：Database Design: One set of tables for each entity type or a generic set for all entity types数据库设计：每个实体类型的一组表或所有实体类型的通用集
【发布时间】：2013-02-22 11:58:29
【问题描述】：

我公司每年都会举办美食节。节日期间举办了许多活动。我的任务是使用 CMS（内容管理系统）设计节日网站。

有 3 种主要类型的实体 - 事件、机构、人员。一个活动有许多参与机构（赞助商、餐厅、酒店）和人员（厨师、酒厂代表、调酒师）。

每个实体可以有许多类别、许多文档、照片库并链接到其他类型的实体。哪个更好 - 案例 1 或案例 2（见下文）？

[CASE 1] - 每种实体类型的一组表：

事件表：event、eventCategory、eventDocument、eventGallery、event_establishment、event_person

机构表：机构、机构类别、机构画廊、机构人员

Person 表：person、personCategory、personDocument、personGallery

personDocument 表的示例列：docId、docFilename

请注意，上面的列对于 eventDocument 和establishmentDocument 将完全相同。

[CASE 2] - 每个实体类型的表、类型表和通用表集：

表：事件、机构、人员、entityType、entityCategory、entityDocument、entityGallery、entity_entity

entityDocument 的示例列：docId、entityTypeId、docFilename

感谢任何建议 - 谢谢！

【问题讨论】：

标签： database entity

【解决方案1】：

这只是我的意见，但我已经这样做了一段时间。

案例 1 是迄今为止最容易维护和最推荐的。您可以管理您的实体，并且根据您用于编写网站的语言，您可以谈论一些 ORM 框架的优势，这些框架将使您的生活再次变得更加轻松。

案例 2，在 SQL 数据库中执行此操作会导致很多问题。你最终会编写很多不必要的代码来尝试检测类型，确保你正在做正确的连接。这将是一场噩梦！我真的想不出这样做有什么好处。

您可能有一个 No-SQL 数据存储的案例 3。像 MongoDB 或 RavenDB。无需担心结构。你输入的就是你输出的，没有任何翻译。（至少使用 RavenDB）。 No-SQLData Stores 对于大型应用程序来说要快得多，但它们确实需要一段时间才能让您正确使用它们。

我建议你选择案例1

【讨论】：

感谢您的建议。我去年使用了案例 1，但一直在考虑是否可以改进 - 补充表（类别、文档、图库）的列是相同的，并且对于每个新的实体类型，需要添加另一组 6 个或更多表.上面显示的画廊过于简单，因为它需要另一个表来保存每个画廊中多张照片的信息。还担心会弄乱 CMS 用户界面。