我正在研究一个使用多个表来表示报告层次结构的应用程序，但这些表中的每个表都是相同的。层次结构底部的表拥有最多的记录，每条记录都有其上方汇总表的 ParentID，最终在顶部汇总表中全部加起来只有一个总数。
我被带有硬编码连接和表名的庞大“if”代码块困扰到精神错乱，我正在努力找出一些不使用单个表的合理原因，而不是在每一行中都有一个 levelID每个级别的一个表，所有这些级别，或同一表上的至少几个视图。后者是因为数据库被设计用于 MSAccess，它不允许别名子查询 AFAIK。
【问题讨论】：
标签： sql database-design
这些表的语义是否都相同或只是形式相同？如果表格在形式和语义上都相同，那么单个表格解决方案可能要好得多，但我对您的情况了解得不够多，无法确定。
在 SQL 表中表示层次结构可能是一个相当大的挑战。幸运的是，报告层次结构通常足够小且足够稳定，因此可以使用各种技术。
最简单的技术称为“邻接表”模型。在此模型中，有两列，其中一列引用另一列。我会称它们为 MyTable(ID, ParentID)。在实际情况下，Mytable 会有其他列。 ParentID 引用同一表的不同行中的 ID。这很容易实现，也很容易更新。进行汇总可能会很痛苦。
另一种技术名为“嵌套集”。称它为 MyTable（ID、lft、rgt、Level）。 （级别是多余的，经常被省略）。这里我们有两列（lft 和 rgt）显示行适合层次结构的位置，因为 lgt 和 rgt 嵌套在所讨论节点的所有祖先的 lft 和 rgt 内。这种技术很难更新。进行汇总、查找子树、祖先路径以及许多其他类型的查询很容易。
“扁平化层次结构”的第三种方法。在这种技术中，层次结构的每个级别都有自己的命名列，并且每一行都显示其整个祖先，一直到层次结构的顶点。这里我们有 MyTable（ID、Division、Department、Group、Team）。 Division，Department，Group和Team是层次结构的所有级别。这对于通过点击向下钻取界面访问数据的用户来说最终很容易，因为如果列名选择得当，他们就没有什么可学习的了。每个级别都需要一个名称。它不能很好地适应不确定的层次结构。它有很多冗余。一般来说，扁平的层次结构是从以邻接列表形式或嵌套集合形式存储层次结构的表中自动生成的。
其中任何一个都可以很好地替代层次结构中每个级别的单独表。
【讨论】：
这里已经推荐了优秀的解决方案。我会添加一个以使用分层数据库，例如超图。
【讨论】：