树数据结构的数据库结构
在数据库中实现可定制（意思是具有未知数量级别的树结构）树数据结构的最佳方式是什么？
在使用带有外键的表格之前，我已经完成了一次。
你可以看到什么其他的实现，这个实现是否有意义？
您提到了最常用的，即邻接列表：https：//blogs.msdn.microsoft.com/mvpawardprogram/2012/06/25/hierarchies-convert-adjacency-list-to-nested-sets
还有其他模型，包括物化路径和嵌套集合：http://communities.bmc.com/communities/docs/DOC-9902
Joe Celko已经撰写了一本关于这个主题的书，这是从一般的SQL角度看的一个很好的参考（它在上面的嵌套文章链接中提到过）。
此外，Itzik Ben-Gann对他的书“Inside Microsoft SQL Server 2005：T-SQL查询”中最常见的选项有很好的概述。
选择模型时要考虑的主要因素是：
1）结构变化的频率 - 树的实际结构变化的频率。 某些型号提供更好的结构更新特性。 但是，将结构更改与其他数据更改分开很重要。 例如，您可能想要模拟公司的组织结构图。 有些人会将此模型作为邻接列表进行建模，使用员工ID将员工链接到其主管。 这通常是次优方法。 通常更好的方法是将组织结构建模与员工本身分开，并将员工作为结构的一个属性进行维护。 这样，当员工离开公司时，组织结构本身不需要改变，只需要与离开的员工建立联系。
2）树是重写还是重读 - 在读取结构时，某些结构工作得很好，但在写入结构时会产生额外的开销。
3）您需要从结构中获得哪些类型的信息 - 某些结构擅长提供有关结构的某些类型的信息。 例子包括查找节点及其所有子节点，查找节点及其所有父节点，查找满足特定条件的子节点的数量等。您需要知道将从结构中需要哪些信息来确定最适合的结构您的需求。
看看在MySQL中管理分层数据。 它讨论了在关系数据库中存储和管理分层（树状）数据的两种方法。
第一种方法是邻接列表模型，这就是您基本描述的内容：具有引用表本身的外键。 虽然这种方法很简单，但对于某些查询（如构建整棵树）可能效率很低。
本文讨论的第二种方法是嵌套集模型。 这种方法更加高效和灵活。 有关详细说明和示例查询，请参阅文章。
如果您必须使用Relational DataBase来组织树数据结构，那么Postgresql有一个很酷的ltree模块，它提供了用于表示存储在分层树状结构中的数据标签的数据类型。 你可以从那里得到想法（欲了解更多信息，请参阅：http：//www.postgresql.org/docs/9.0/static/ltree.html）
通用的LDAP用于组织分层结构的记录。
链接地址: http://www.djcxy.com/p/93869.html