我无法通过规范化的关系数据库设计来描述一个与典型的层次结构示例有足够差异的小层次结构，这样我就不能确定如何处理这样的问题。
我的问题如下：
层次结构中的每个分支都保证深度为2级，4级或6级。 如果它是2级深度，则层次结构如下所示：
Category / Group / Component
如果它是4级深度，它看起来像这样：
Category / Group / Component / Group / Component
如果深度为6级，则看起来像这样：
Category / Group / Component / Group / Component / Group / Component
类别，组和组件都有自己的一组属性。更复杂的是，组件与实体A，组件和实体B以及组件和实体C之间存在关系。
我最初的想法是努力将组件保留在一个表中，但是，我无法提出满足此目标的规范化解决方案。
相反，我想出了一个规范化的解决方案，其中在三个可能的组件级别的每一个都有一个单独的组件表。但是，我对此并不十分满意，因为它使得捕获组件之间链接的表的数量增加了三倍，并使A，B和C具有权限（如果所有组件都在一个表中，则总共9个链接表而不是3个。）
以下是我想出的设计：
TABLE: Group_1_Components
ATTRIBUTES: Row_ID, Category, Component
RELATES-TO: Group_1_Components_A_Links, Group_1_Components_B_Links, Group_1_Components_C_Links, Group_2_Components
TABLE: Group_2_Components
ATTRIBUTES: Row_ID, Group, Component, Group_1_Component_Row_ID
RELATES-TO: Group_2_Components_A_Links, Group_2_Components_B_Links, Group_2_Components_C_Links, Group_1_Components, Group_3_Components
TABLE: Group_3_Components
ATTRIBUTES: Row_ID, Group, Component, Group_2_Component_Row_ID
RELATES-TO: Group_3_Components_A_Links, Group_3_Components_B_Links, Group_3_Components_C_Links, Group_2_Components
9个链接表中的每一个都包含两个行ID，用于解决与表A，B或C的多对多关系。
这是一个合理的设计还是我忽略了一个更简单，更典型的解决方案？我查看了一些特定于在关系数据库中捕获层次结构的设计技术，特别是邻接列表，但我不确定它们是否适合这里，它们似乎也不是标准化解决方案。
应该注意的是，层次结构很少会被修改;它将经常被读取，其中读取检索所选组的特定级别的所有组件或组件。实体A，B和C的链接表将定期写入。
欢迎任何和所有建议。在此先感谢您的帮助。布赖恩
答案 0 :(得分：1)
我建议您对数据进行反规范化，以使您的层次结构基于组件/组实体，以便匹配“常规”层次结构。在这种情况下，您可以使用以下表格：
a）组件
b）小组
c）Component_Groups - 在component_id和group_id上使用唯一键，以确保每个组件和组只有一个组合
在这种情况下，您的层次结构将是：类别 - ＆gt; Component_Group - ＆gt; Component_Group - ＆gt; Component_Group
答案 1 :(得分：0)
此类问题的另一个选择是使用自引用表。只有一张桌子。
包含ID，PARENT_ID和TYPE的单个表，以便您可以区分CATEGORY，GROUP和COMPONENT。
所有类别都没有PARENT_ID，然后您可以搜索所有子对象，其中父ID等于您想深入的类别的ID。