3

我认为问题的典型形式是你有员工，员工有经理，所以经理有经理，除非他是 CEO。

那么如何存储数据呢？解决方案 1：似乎员工表可以有 manager_id 或者您可以有一个employee_manager 表（这样您可以有多个或零个经理）。

有人说解决方案 1 是个坏主意，因为 SQL 不支持递归，并且没有查询可以找到员工之上的所有经理。这些人有不同的想法（比如员工有一份经理名单），但是他们似乎都涉及到一堆非常难以维护的非规范化数据。

那么大家怎么看呢？

4

4 回答 4

4

我同意其他人..递归是可用的。

我不会将 manager_id 放在 emp 表中（尽管有 SCOTT/TIGER 古老的智慧）。现实世界无时无刻不在打破这个商业规则，并没有很好的规范化。

而是考虑一个 person_to_person 类型的链接表，其中两个人在某个时间段内相互关联，并具有角色……例如，从 1 月到 3 月，person1 作为经理与 person2 相关。这使您可以非常灵活地将人员分配到项目、部门、任意组，即使在某些时间点有多个经理也是如此。

还要考虑人员与部门的关系是相似的——人们可能同时以微妙的方式与多个部门相关联。

于 2011-10-31T21:31:12.110 回答
3

大多数流行的 SQL 数据库都支持递归查询。

  • 大多数数据库都支持递归 CTE。
  • Oracle 还支持CONNECT BY。
  • 不幸的是，MySQL 也不支持。
于 2011-10-31T21:20:34.923 回答
2

您必须决定在哪里强制执行数据的完整性约束，以及在哪里查询它/用它做有趣的事情。

正如其他人所提到的，一些数据库服务器不支持递归查询；但是，如果您要查询数据库，然后在代码中构建一棵树——那么这是一个有争议的问题。

但即使你可以在 SQL 中做到这一点——你真的想要吗？SQL 适用于某些事情，但并非适用于所有事情。

主要关注点应该是让数据库做它擅长的事情——在这种情况下，这听起来像解决方案 1。

于 2011-10-31T21:36:53.137 回答
1

一些数据库确实有递归查询，比如CONNECT BYOracle 中的构造。在这种情况下，我当然会选择 1。

但即使不是，我认为如果你给每个人自己的经理，如果这确实是数据的结构，数据会更干净。您需要运行多个查询以将所有经理都交给 CEO，或者您必须获取所有数据并以您使用的任何编程语言构建树。但是如果每个人都有一份经理名单，你就会遇到同样的问题。如果你想用这些数据构建一棵树，你将需要一些编程智能。除非你有甲骨文，否则就是这样。;)

顺便说一句，我会选择列出部门列表，并为每个部门指定一名经理。这样，您可以更轻松地将人员（甚至经理）置于不同的位置，而无需更新员工。通常经理管理一个部门，所以他们只是其他人的经理，因为那些人​​在那个部门工作。

于 2011-10-31T21:22:08.170 回答