我正在研究一个使用多个表来表示报告层次结构的应用程序的怪异性，但这些表的eacvh是相同的。层次结构底部的表具有最多记录，每个记录对其上方的汇总表具有ParentID，最终在顶部汇总表中最多只添加一个总计。
我被巨大的'if'代码块与硬编码的连接和表名称所困扰，我正在努力认识到不使用单个表的一些理智的原因，每行都有一个levelID，而不是每个级别的一个表，所有这些级别，或同一个表上的至少几个视图。后者因为数据库被设计用于MSAccess，它不允许别名子查询AFAIK。
答案 0 :(得分：4)
这些表的语义是否完全相同或只是形式？如果表格在形式和语义上都相同，那么单个表格解决方案可能会更优越，但我对您的情况了解不够充分。
在SQL表中表示层次结构可能是一个非常大的挑战。幸运的是，报告层次结构通常足够小且足够稳定，因此可以使用各种技术。
最简单的技术是名称“邻接列表”模型。在这个模型中，有两列，其中一列是另一列。我将它们称为MyTable（ID，ParentID）。在实际案例中，Mytable将包含其他列。 ParentID引用同一表的另一行中的ID。这很容易实现，并且易于更新。汇总可能会很痛苦。
另一种技术名称为“嵌套集”。称之为MyTable（ID，lft，rgt，Level）。 （级别是多余的，并且经常被省略）。这里我们有两列（lft和rgt）显示行适合层次结构的位置，因为lgt和rgt嵌套在所讨论节点的所有祖先的lft和rgt中。这种技术很难更新。它很容易进行汇总，查找子树，祖先路径以及许多其他类型的查询。
“扁平化层次结构”的第三种方式。在此技术中，层次结构的每个级别都有自己的命名列，每行显示其整个祖先一直返回到层次结构的顶点。这里我们有MyTable（ID，Division，Department，Group，Team）。部门，部门，团队和团队是层次结构的所有级别。对于通过点击式下钻界面访问数据的用户来说，这最终很容易，因为如果选择好列名，他们就无需学习。它需要每个级别的名称。它不能很好地适应不确定的层次结构。它有很多冗余。通常，展平的hiearachies是从一个表中自动生成的，该表以附件列表形式或嵌套集形式存储层次结构。
这些中的任何一个都是层次结构中每个级别的单独表的一个很好的替代方案。
答案 1 :(得分：-2)
这里已经提出了很好的解决方案。我会添加一个使用分层数据库，如超图。