我认为问题的典型形式是你有员工，员工有经理，所以经理有经理，除非他是首席执行官。
那你如何存储数据呢？解决方案1：看起来employee表可以有manager_id，或者你可以有一个employee_manager表（这样你可以有很多或者没有经理）。
有些人说解决方案1是一个坏主意，因为SQL不支持递归，并且没有查询来查找员工以上的所有经理。这些人有其他想法（比如员工有一个管理人员名单），但他们似乎都涉及一堆非常难以维护的非标准化数据。
那么你们都在想什么？
答案 0 :(得分：4)
我同意其他人的意见..递归可用。
我不会将manager_id放在emp表中（尽管有SCOTT / TIGER的古老智慧）。现实世界一直在破坏这一商业规则，并且没有很好地规范化。
改为考虑person_to_person类型链接表，其中两个人在具有角色的时间段内彼此相关...例如，person1与作为经理的1月到3月的person2相关。这使您可以灵活地将人员分配到项目，部门，任意组中，即使在某些时间点拥有多名经理的现实。
还要考虑人与部门的关系是相似的 - 人们可能会以微妙的方式同时与多个部门联系。
答案 1 :(得分：3)
大多数流行的SQL数据库做支持递归查询。
答案 2 :(得分：2)
您必须决定在何处强制执行数据的完整性约束，以及在何处查询/使用它执行有趣的操作。
正如其他人所提到的，某些数据库服务器不支持递归查询;但是，如果你要查询数据库，那么在代码中构建一个树 - 那么这是一个没有实际意义的点。
但即使你能在SQL中做到这一点 - 你真的想要吗？ SQL对于某些事情很有用，但对所有事情都不是。
主要的关注点应该是让数据库做他们擅长的事情 - 在这种情况下，听起来像解决方案1。
答案 3 :(得分：1)
某些数据库确实有递归查询，例如Oracle中的CONNECT BY构造。在那种情况下，我当然会选择1.
但即使不是，我认为如果你给每个人都是他自己的经理，那么数据会更清晰，如果这确实是数据的结构。您需要运行多个查询以使所有管理员都能够获得CEO，或者您必须获取所有数据并使用您正在使用的任何编程语言构建树。但是如果每个人都得到一份经理名单，你就会遇到同样的问题。如果要从这些数据中构建树，则需要一些编程智能。除非你得到Oracle，否则就是这样。 ;）
顺便说一下，我会选择制作一个部门清单，并给每个部门一个经理。这样，您可以更轻松地将人员（甚至是经理）置于不同的位置，而无需更新员工。通常管理者管理一个部门，所以他们只是其他人的经理，因为那些人在那个部门工作。