Database design 支持仅适用于特定行的值的最佳数据库模式是什么？

我有一个名为“日历”的db表，其中包含字段

Id（主键）

名字

描述

CalendarTypeId（FK进入CalendarType表格）

我有另一个名为CalendarType的表，其中包含字段

Id（主键）

名字

描述

问题是我需要为日历类型为2的每个日历存储一个附加字段。（但此字段与任何其他日历类型无关）

---

我是否应该在日历表中创建一个新字段，并对所有其他具有不同calendarTypeid的日历忽略该字段，或者是否有更好的方法来组织此架构以支持此需求。

您可以使用单表继承模式，这与您的建议非常接近

或

---

如果您想专门化一些表以匹配您试图在数据库中表示的类型（Calendar和CalendarType2），我可能会使用Calendar。我称之为数据库表重载。当数据存储很昂贵时，这是一种犯罪。现在它被称为用简单的方法解决问题，然后继续前进。除非你真的需要，否则不要过度设计

---

但是，您没有明确说明typeID为2的每个日历实例的额外字段值是否不同。有时，我的类型表有子类型字段等，但我会假设在这种情况下，类型2的日历实例在所需字段中将有不同的值

好的，这是您当前拥有的ER模型（省略基数）：

现在，让我们关注日历和子日历。很明显，你有一个等级制度。但是层次结构是如何变成表的呢？有三种常见的方法可以做到这一点：

1） 杀死父实体并保留子实体：在这种情况下，删除父实体并将该实体中的所有字段发送给每个子实体。在您的示例中，您只有一个子项，因此所有父项的属性都将只指向它

优点：没有空值，因为每个表都有它需要的所有内容。也不需要连接。如果要运行查询，只搜索一种类型的子项，则此模式将非常有用，因为您不需要按类型进行筛选，因为每个表只存储一种类型

缺点：这种模式不适合有重叠子项的情况。换句话说，如果父行在向每个子行发送字段时可以有多个子行，则父行数据将在每个子行中重复。不好，所以如果是这样的话，不要使用这种策略。此外，如果每个表中有很多子表，但记录很少，那么会有很多表，每个表中的记录很少，因此管理起来可能会有点困难

2） 杀死子项并保留父项：在这种情况下，删除所有子项并将其所有属性发送给父项。由于父级现在是自身及其所有子级的混合体，因此需要一种方法来确定哪一行属于哪种类型的子级。这是通过向父实体添加一个新属性来实现的，该属性将确定每行的类型（无论数据类型如何）

优点：所有儿童只有一张桌子，因此易于管理。不需要连接。如果针对该表运行的大多数查询需要来自多个类型的子项的结果，则可能非常有用

缺点：同样，如果父级可以有一个与多个子级相关的行，则数据将被复制，因为每个子级都有一行，因此此解决方案有一个限制。此外，必须添加一个新列作为元数据。表中的记录量将更大。必须将空值分配给子级拥有的数据以及父级或其他子级拥有的数据

3） 保留所有内容：最不血腥的解决方案是不杀掉任何东西：）在这种情况下，层次结构被父级和每个子级之间的关系所取代。这样，子表必须通过外键连接到父表才能访问父表的数据

优点：没有数据重复，也没有空值。每个实体只有最少的数据量，其余的数据可以通过连接到父表来获得。在这种情况下，父行可以链接到多个子行，而无需复制数据。如果将运行多个查询，而这些查询只能使用一个表（通常是父表）来满足，那么这是一个很好的选择。还有一件事是，很容易扩展到更多日历，例如，如果要添加需要新字段的新日历，则必须添加新表，而不修改当前表

缺点：需要最多的表（实际上比第一个多一个）。每个子级都需要一个连接，这将降低数据集越大的性能。此外，连接这两个表还需要外键。如果大多数查询需要来自父级和子级的数据，则此模式的性能将最差

现在，您询问哪个是

最佳的

数据库模式。我认为现在很清楚，这取决于需求、将运行的查询类型、数据的结构方式等

不过，我可以对此进行更多的分析。您说过您有一个日历表，有时其中一个需要更多数据。所以我们可以说我们有两种日历，父日历和子日历。所以我们可能认为使用解决方案2是一个很好的可能性，因为您将有两行代表每种类型，但我们错了。这是因为在这种情况下，每个子级都包括其父级。现在，如果我们可以假设if

子属性

对于子属性总是非空的，对于