我有三个实体Plan, Feature, Sensor用表表示，使用如下相同的结构:
[Entity]
--------
Id (int)
Name (varchar)
每个实体以1-多关系链接到另一个实体:
每个Plan可以有多个Features
每个功能可以有多个传感器s(注意不同的功能可能有共同的传感器，但有不同的要求级别-可选/强制)
该数据将在应用程序中使用，用户将选择一个计划，并最终将显示所需传感器的列表。
设计问题#1:
我首先想有一个表来描述Plan和Feature之间的关系，我的想法是有一个表:
PlanFeatures
--------------
PlanId (int)
FeatureId (int)
Required (bit)
如果我有一个Required列，那么我将有效地需要对PlanId和FeatureId的每个组合进行记录。另一种选择是仅在PlanId和FeatureId组合存在的情况下添加记录。哪个更好?
设计问题#2
与#1类似，我希望有一个表来描述功能和传感器之间的关系，唯一的区别是传感器可能不是必需的/可选的/强制性的。因此，我们的想法是有一个表如下:FeatureSensors
--------------
FeatureId(int)
SensorId(int)
RequirementLevel(int)
至于#1，我质疑我是否需要对FeatureId和SensorId的每个组合都有一个记录，如果不需要，那么我只需为requientlevel使用0，否则我只有一个记录，它是可选的(1)或强制性的(2)。
我在这里走的是正确的路径还是有更好的方法来构建这个数据?
首先，原则上这绝对是一种方法。通过"关系表"连接表;(编辑:不知道这些是否有正式名称)是一种已知的做法。
甚至在我读完这篇文章之前，我就问了自己关于第1个问题的问题:为什么你需要记录计划和功能的每一个组合?同样，为什么您需要为特性和需求的每个组合创建一个记录呢?我只是将实际应用的组合存储在数据库中，而不存储根本不使用的组合。
需求级别(可选/强制)可以存储为布尔标志;例如，可以将其重命名为"required_flag"或者类似的东西。如果该标志设置为true，则表示规划/特性分别需要feature/sensor。如果标志为false，则组合是可选的。这样，您还可以在两个表中获得需求级别的统一表示。