这个设计问题变得比我预期的更“有趣”......
对于上下文，我将实现我在Access 2007中获得的任何解决方案（没有多少选择 - 客户要求。我可能能够将它们转换为不同的后端，但前端end必须是Access（因此是VBA和Access SQL））。我期望围绕这些表的两个主要活动是从平面文件批量导入新结构并报告结构（整个结构的完全递归）。实际上没有删除或更新（除了整个树在创建新版本时被标记为非活动状态）。
我正在处理两个主要表格，并想知道我是否真正掌握了如何将它们联系起来：产品和零件（还有其他一些，但相比之下它们非常简单。）
产品由零件组成。零件可用于多个产品，大多数产品使用多个零件。我认为正常的多对多分辨率表可以满足这个要求（大多数情况下 - 我会在一分钟内重新审视）。我将这个产品称为部分。
“有趣”部分是许多零件也由零件组成。再一次，给定的部件可以用在多个父部件中（甚至在单个产品中）。不仅如此，我认为我必须将递归级别的数量视为有效任意。
我可以捕捉从零件到零件的m-to-m分辨率的关系，将每个非根部件与其直接的父部件相关联，但我有一种潜在的怀疑，即我可能会因为悲伤而陷入困境。我止步我将这部分称为部分。我遇到了几个问题：
我是否因为对此感到疑惑而烦恼？换句话说，我应该如上所述实施两个分辨率表，并且不要担心吗？
我是否还应为每个非根部件的所有祖先创建零件部分行，并在表格中添加一列来存储代数？
产品部件是否应包含产品中每个零件的行，或仅包含根零件？如果它是所有部件，那么生成指标是否有用？
我（就在今天，来自相关问题），看看嵌套集的设计方法。看起来它可以简化一些要求（特别是在报告方面），但是考虑在导入产品导入中的数百个（偶尔数千个）部件时生成树，这让我在睡觉之前做噩梦。我最好咬这个子弹并以这种方式前进吗？
除了上面提到的具体问题，我还要感谢结构设计的任何其他评论，以及关于如何处理这个问题的提示，无论是入境还是出境（虽然我担心我不能接受改变语言/ DBMS环境的建议。）
答案 0 :(得分：1)
物料清单和爆炸零件清单总是非常有趣。我将实现Parts作为您的主表，使用布尔字段来表示某个部分是“可销售”。这将删除本身产品的第一级递归差异和部分冗余。然后，将Products实现为可销售部件的视图。
您使用PartPart交叉引用表处于正确的轨道上。在该表上实现一个约束，该约束表明父部件和子部件不能是相同的部件ID，以节省一些带有无限递归的麻烦。
BOM之间的代际差异可以通过在实际更改级别创建新零件来维持，并且可以在任何更高级别中保持更改（如果您想要说这个新零件，作为其一部分）父层次结构，产生新产品）。然后更新在此代更改中未修订的任何零件级别的参考树（以维护子级不应该生成的零件和产品）。为了避免孤儿（从顶层无法访问的未引用的部件记录），部件可以直接引用其前任，创建祖先的链接列表。
这是一个非常复杂的网络，可以肯定;类似表示的对象的持久树状结构通常是。但是，如果你聪明地实现约束来强制引用完整性并避免无限递归，我认为它是可管理的。
答案 1 :(得分：0)
我将有一个原子零件的零件表，然后是一个带有superpartID及其相关子零件的超零件表。然后你可以有一个产品/超级表。 如果一个部分也是一个超级部分，那么你只需要一行具有相同partID的superpartID。
也许'组件'比超级组件更好。例如，组件可以在更大的组件中重用。
答案 2 :(得分：0)