我认为问题的典型形式是你有员工，员工有经理，所以经理有经理，除非他是 CEO。
那么如何存储数据呢？解决方案 1：似乎员工表可以有 manager_id 或者您可以有一个employee_manager 表（这样您可以有多个或零个经理）。
有些人说解决方案 1 是个坏主意，因为 SQL 不支持递归，并且没有查询可以找到员工之上的所有经理。这些人有不同的想法（比如员工有一份经理名单），但他们似乎都包含一堆非常难以维护的非标准化数据。
那么大家觉得呢？
【问题讨论】：
标签： sql tree-structure
我同意其他人的观点。递归可用。
我不会将 manager_id 放在 emp 表中（尽管有 SCOTT/TIGER 古老的智慧）。现实世界无时无刻不在打破这个商业规则，而且没有很好的规范化。
请考虑一个 person_to_person 类型的链接表，其中两个人在某个时间段内以某个角色相互关联...例如，从 1 月到 3 月，person1 与 person2 作为经理相关。这使您可以非常灵活地将人员分配到项目、部门、任意组，即使在某些时间点有多个经理也是如此。
还要考虑到人员与部门的关系是相似的——人们可能同时以微妙的方式与多个部门相关。
【讨论】：
大多数流行的 SQL 数据库确实支持递归查询。
【讨论】：
您必须决定在哪里实施数据的完整性约束，以及在哪里查询它/用它做有趣的事情。
正如其他人所提到的，一些数据库服务器不支持递归查询；但是，如果您要查询数据库，然后在代码中构建一棵树——那么这是一个有争议的问题。
但即使你可以在 SQL 中做到这一点——你真的想要吗？ SQL 适用于某些事情，但并非适用于所有事情。
主要关注点应该是让数据库做它擅长的事情——在这种情况下，这听起来像解决方案 1。
【讨论】：
某些数据库确实具有递归查询，例如 Oracle 中的 CONNECT BY 构造。在那种情况下，我当然会选择 1。
但即使不是，我认为如果你给每个人自己的经理，如果这确实是数据的结构，数据会更干净。您需要运行多个查询以将所有经理都交给 CEO，或者您必须获取所有数据并以您使用的任何编程语言构建树。但是如果每个人都有一份经理名单，你就会遇到同样的问题。如果你想用这些数据构建一棵树，你将需要一些编程智能。除非你有甲骨文，否则就是这样。 ;)
顺便说一句，我会选择列出部门列表，并为每个部门指定一名经理。这样，您可以更轻松地将人员（甚至经理）置于不同的位置，而无需更新员工。通常经理管理一个部门，所以他们只是其他人的经理，因为这些人在那个部门工作。
【讨论】：