用于链接 3 个实体的 SQL Server 表设计建议答案

【问题标题】：SQL Server table design advice for linking 3 Entities用于链接 3 个实体的 SQL Server 表设计建议
【发布时间】：2021-12-09 00:08:39
【问题描述】：

我有三个实体Plan、Feature、Sensor，用表表示，结构相同，如下所示：

[Entity]
--------
Id (int)
Name (varchar)

每个实体通过一对多关系链接到另一个：

每个计划可以有多个功能

每个功能可以有多个传感器（请注意，不同的功能可能有共同的传感器，但有不同的要求级别 - 可选/强制）

此数据将在用户选择计划并最终显示所需传感器列表的应用程序中使用。

设计问题 #1：

我首先想要一个表格来描述 Plan 和 Feature 之间的关系，而我的想法是有一个表格：

PlanFeatures
--------------
PlanId (int)
FeatureId (int)
Required (bit)

如果我有一个 Required 列，那么我实际上需要为 PlanId 和 FeatureId 的每个组合记录。另一种方法是仅在存在 PlanId 和 FeatureId 组合时添加记录。哪个更好？

设计问题 #2

与 #1 类似，我想要一个表格来描述 Features 和 Sensors 之间的关系，唯一的区别是 Sensor 可能不是必需的/可选/强制。所以想法是有一个如下表：

FeatureSensors
--------------
FeatureId(int)
SensorId(int)
RequirementLevel(int)

至于 #1，我在质疑是否需要为 FeatureId 和 SensorId 的每个组合记录，如果不需要，那么我只需将 0 用于 RequirementLevel ，否则我只有可选（1）或强制（2）的记录。

我是走在正确的道路上还是有更好的方法来构建这些数据？

【问题讨论】：

一个Feature可以属于多个Plan吗？如果没有，那么您无论如何都不需要另一张桌子。如果是，我建议仅在需要存在时才拥有记录，并且没有Required。在第二种情况下：同样的问题。我只建议Optional 和Mandatory 级别

【解决方案1】：

首先，原则上这绝对是一种方法。通过“关系表”连接表（编辑：不知道这些表是否有正式名称）是一种已知做法。

甚至在我读完之前，我就问过自己一个与问题 1 相同的问题：为什么您需要为每个计划和功能组合记录？同样，为什么您需要为每个功能和需求组合记录？我只是将实际应用的组合存储在数据库中，而不存储根本不使用的组合。

然后可以将需求级别（可选/强制）存储为布尔标志；即可能将其重命名为“required_flag”或类似的东西。如果该标志设置为 true，则计划/功能分别需要功能/传感器。如果标志为假，则组合是可选的。这样，您还可以在两个表中统一表示需求级别。

【讨论】：