Sql 当用户选择“时如何处理记录”；“全部”；记录？

我有一个要求，用户希望“所有”选项是几个字段

1.站点约有20条记录（包括All选项）

2.依赖于1的成本中心站点的总记录约为540个，包括所有站点。营业点可能有不同数量的成本中心（包括所有选项）

3.依赖于2的员工。成本中心的总记录约为29000人。每个成本中心可能包括不同数量的员工。（包括所有选项）

4。过程与上述所有过程无关。它包括大约20条记录。（包括所有选项）

现在，站点、成本中心、员工和流程都有下拉菜单，带有“所有”以及其他选项

如何设计数据库表。考虑以下情况

用户选择以下选项：

站点：利雅得

成本中心：医学硕士

员工：所有员工

处理：旅行请求和授权

用户已在成本中心中全力以赴

网站：吉达

成本中心：所有

员工：所有员工

处理：所有

同样，也很少有其他组合。以及用户应如何查看插入的记录，以便他/她可以轻松导航到记录并更新/删除它。现在我正在考虑为选项“All”插入单个记录。例如

用户选择：

站点：利雅得

成本中心：护理

员工：所有员工

处理：所有

这将在数据库表中只插入一行

用户要求，如果他在所选的成本中心下有200名员工，并且他只想申请70名员工。他需要做更多的工作

---

用户随后如何编辑插入的记录。以及如何呈现所有记录的视图，以便于用户编辑特定记录。

您没有对数据中的所有内容进行建模，或者您必须处理将员工错误分配到名为all的站点下名为all的成本中心的人。你不会想要的

站点有成本中心，成本中心有员工，有流程，并且（我假设）员工可能被分配给它们，这意味着一个将员工链接到流程的表。只存储真实数据

然后，在查询中要明智，这样，如果用户为给定的下拉列表选择ALL，他们将获得所有匹配的记录，并且插入的数据必须满足适当的引用完整性。成本中心必须属于有效的站点。员工必须属于成本中心，并且可能有一个或多个与其链接的流程

---

但是放上“全部”占位符？如果你沿着这条路走下去，你将为自己打开一个管理虚拟关系与真实关系的世界。

事实上，你在站点和成本中心之间有两种关系（我只将其缩小到这两种实体）。两者都是可选的，必须定义其中一个

第一个关系是（无问题的）站点到成本中心的零对一关系（包括成本中心已知并分配给站点的情况）

第二种关系涵盖了这种情况，即没有分配成本中心，成本必须“以某种方式分配”。“全部”可能意味着每个成本中心（比如）获得相等的份额

这种一分为二的关系使数据库设计更加清晰，但它不会解决主要问题，即查询关系

问题表现在连接谓词中的或条件（追逐两条路径），这可能导致次优性能

因此，这是您设计的试金石，收集主要查询并检查它们对示例数据的执行情况

---

解决性能问题的一种可能方法是定义物化视图，将所有关系扩展到每个成本中心（如@Michael所建议的），并且在新的成本中心定义时可以刷新这些视图，因此您无需手动处理此类更改。

这在静态系统中效果良好。如果创建了新的成本中心，会发生什么？所有扩展的“到所有”关系都应该扩展？是否有真正的“所有”关系需要建模？从描述中很难说，因为他似乎在讨论用户查询-“用户选择“全部”用于此类别”等等。在我看来，站点和呼叫中心是实体的，可能需要对关系进行不同的建模，但是否有一个呼叫中心实体“全部”连接到一个或多个站点实体？如果是这样的话，那么我们谈论的全成本中心是什么版本？站点1还是站点2？允许对其采取什么行动？抱歉-我只是不同意创建psuedo实体来模拟复杂关系完全同意-实体没有伪实例。“是的，构造几乎是清晰的。”迈克尔·布罗顿同意，只需要插入真实的数据。这是插入具有流程名称的员工。在这种情况下，假设场地是利雅得，成本中心是All（全部在利雅得场地下）。它有大约7000名员工，每个员工需要3个流程。在这种情况下，我需要插入21000条记录。甚至用户也可以选择20个左右的所有进程。因此，需要插入140000条记录。