Database 我应该合并这些数据库表吗。

我有一个带有sql数据库的事件日历应用程序，现在我有3个表来表示事件：

表1：假日
列：ID、日期、名称、位置、日历ID

表2：假期
列：Id、日期、名称、PersonId、WorkflowStatus

表3：事件
列：Id、日期、名称、日历Id

所以我有“一般事件”进入事件表，特殊事件如假期和假期进入这些单独的表。我正在讨论如何将这些合并到一个表中，并在通用事件中使用location和personid blank等列

表1：事件：
列：Id、日期、名称、位置、PersonId、WorkflowStatus

---

是否有人认为每个选项都有积极或消极的一面。显然，有些记录的列不一定适用，但与这三个表有重叠。

如果这是我的决定，我会将它们压缩成一个表。我将添加一个名为“EventType”的列，并在将数据导入新表时更新该列，以指定事件的类型

---

这样，您只需要索引一个表而不是三个表（如果您觉得需要索引），数据都在一个表中，并且获取数据的查询会更简洁一些，因为您不需要将所有三个表合并在一起来查看一个人做了什么。我不认为将所有内容都放在一个表中有什么坏处（尽管可能有人会提出一个我没有想到的表）。

无论采用哪种构造方式，应用程序都必须处理变量类型。在这种情况下，我建议您在DBM中使用单个表示，因为另一种选择是需要多个查询

---

因此，这就成了一个问题，你把复杂性放在哪里，即使在一个庞大的组织中，也很难生成足够多的事件来担心DBMS的优化。应用程序代码比硬连线模式更灵活。这是一个偏好问题。

将它们保存在3个单独的表中，如果需要将数据合并到一个结果集以供使用，请在视图中执行

UNION ALL

。只要性能足够，在磁盘上存储数据的方式不一定与使用数据的方式相同

正如您现在看到的，没有任何列不适用于任何呈现的实体。如果要将这3个表合并为一个表，则必须至少添加一个字段，以了解希望填充哪些列并降低性能。现在，当您单独查询假日时，您将转到数据的子集，您必须对其进行筛选/索引，以便在合并存储表中获得相同的数据

如果您还没有定义这些表，可以考虑创建一个具有以下签名的表…

create table EventBase (
  Id int PRIMARY KEY,
  Date date,
  Name varchar(50)
)

…还有，比如说，带有以下签名的假日桌

create table holiday (
  Id int PRIMARY KEY,
  EventId int,
  Location varchar(50),
  CalendarId int
)

---

…并在需要时加入两者。在这张表和您已经拥有的3张单独的表之间进行选择取决于您计划如何使用这些表和卷，但我绝对不会将所有内容都按原样放在一张表中，并且在没有其他启动的情况下让查看表定义的人看得不太清楚。

将特殊事件分为

事件如何超型？这样以后就很容易添加任何新的特殊事件

或组合公共字段并分离出唯一字段：

表1:EventCommon

列：EventCommonID、日期、名称

表2:EventOrHoliday

列：EventCommonID、CalendarID、isHoliday

表3：假期

列：EventCommonID、PersonId、WorkflowStatus

EventCommon和其他2之间有1->多个关系。
将它们放在一个表中最大的缺点是数据完整性。由于这些字段似乎都是必需的，因此在默认情况下，您将无法要求所有字段，并且必须编写触发器以确保正确维护数据完整性（是的，这必须在数据库中维护，而不是像一些人认为的那样，由应用程序维护。当然，除非您希望有数据完整性问题。）

另一个问题是，这些是您现在需要的事件，将来可能会有越来越多的专门事件，并且可能会破坏某类事件的代码，因为您添加了另一个只适用于其他事件的专门字段，这是一个很大的风险。当您更改以添加一些必需的假期信息时，您确定吗要检查它是否不会中断有关假日的应用程序？或者更糟糕的是，它不会出错，但会显示您不想要的信息？您是否每次都要查看实际屏幕？仅对代码进行单元测试可能不会发现这种情况，尤其是如果有人愚蠢地使用select*或未能在insert.fr中指定列很明显，并不是每个组织都有一个真正彻底的自动化测试过程（如果你这样做的话，风险可能会更小）

我个人倾向于使用Damir Sudarevic的解决方案。一个用于所有公共字段的事件表（至少可以轻松获得所有事件的列表）对于非公共字段的专用表，编写只影响一个事件的代码并允许数据库保持其完整性更为简单。
您是如何生成ERD的？