我认为问题的典型形式是您的员工和员工都有经理，因此经理除非是首席执行官才有经理。将树木数据存储在数据库中的最佳做法
那么你如何存储数据呢？解决方案1：似乎员工表可以有manager_id，或者你可以有一个employee_manager表（这样你可以有很多或零管理器）。
有人说解决方案1是一个坏主意，因为SQL不支持递归，并且没有查询来查找雇员上方的所有经理。这些人有其他的想法（比如员工有一个管理人员名单），但他们似乎都涉及非常难以维护的非标准化数据。
那么你们都在想什么？
我同意他人..递归是可用的。
我不会把manager_id放在emp表中（尽管SCOTT/TIGER古老的智慧）。现实世界总是打破这个商业规则，并且它不是很规范。
改为考虑person_to_person类型的链接表，其中两个人在某个时间段内与某个角色相互关联......例如person1与从1月到3月的person2相关，作为经理。这使您可以灵活地将人员分配到项目，部门，任意团队，即使在某些时间点有多位管理人员的现实。
也认为人与部门的关系是相似的 - 人们可能同时以微妙的方式与多个部门相关联。
最流行的SQL数据库做支持递归查询。
某些数据库确实有递归查询，如Oracle中的CONNECT BY构造。在这种情况下，我肯定会选择1.
但即使没有，我认为如果你给每个人他自己的经理，如果这确实是数据的结构，数据就会更清晰。您需要运行多个查询才能让所有经理接近首席执行官，或者您必须获取所有数据并使用您使用的任何编程语言构建树。但是如果每个人都得到一个经理名单，你也会遇到同样的问题。如果你想从这些数据中构建一棵树，你将需要一些编程智能。除非你有Oracle，否则。 ;）
顺便说一下，我会选择制定部门清单，并给每个部门一个经理。这样，您可以更轻松地将员工（甚至是经理）置于不同的位置，而无需更新员工。通常管理者管理一个部门，所以他们只是其他人的管理者，因为那些人在该部门工作。
您必须决定在哪里执行数据的完整性约束，以及在哪里查询/执行有趣的事情。
正如其他人所说的，一些数据库服务器不支持递归查询;然而，如果你要查询数据库，然后在代码中构建一棵树 - 那么这是一个有争议的问题。
但即使你可以在SQL中做到这一点 - 你真的想吗？ SQL对于某些事情非常有用，但不适用于所有事情。
关注的首要问题应该是让数据库做什么这是很好的 - 在这种情况下，听起来像解决方法1.
[公用表表达式（http://stackoverflow.com/tags/common -table-expression/info）是ANSI-99 SQL标准的一部分，并提供执行递归查询的能力。 – Allan