我要求用户想要“全部”选项是少数几个字段。
1.Sites 的记录大约为20（包括全部选项）
依赖于 1.Site 的2.Cost Centers 的总记录数约为540，包括所有网站。网站可能包含不同数量的成本中心（包括全部选项）
依赖 2.Cost Centers 的3.员工的总记录约为29000.每个成本中心可能包含不同数量的员工。 （包括全部选项）
4。流程以上都是独立的。它包括20左右的记录。（包括全部选项）
现在网站，成本中心，员工和流程的下拉列表中包含“ 所有 “以及其他选项。
我将如何设计数据库表。考虑以下情况
网站：利雅得
成本中心：MA - Medical
员工：全部
流程：差旅申请和授权
网站：吉达
成本中心：全部
员工：全部
流程：全部
同样很少有其他组合。用户应该如何看待插入的记录，以便他/她可以轻松导航以记录和更新/删除它。现在我正在考虑为选项“全部”插入单个记录。例如，
用户选择：
网站：利雅得
成本中心：护理
员工：全部
流程：全部
这将在数据库表中只插入一行。
用户要求如果他在选定的成本中心下有200名员工，并且他只想申请70名员工。他需要做更多的工作。
用户如何编辑之后插入的记录。并且应该如何呈现所有记录的视图，以便为用户编辑特定记录。
答案 0 :(得分：0)
您不会在数据中对ALL进行建模，或者您必须处理人员错误地将员工分配到名为all的站点下名为ALL的成本中心。你不想要那个！
站点有成本中心，成本中心有员工，有流程和（我假设）员工可能被分配给他们，因此暗示了一个将员工与流程联系起来的表。仅存储REAL数据。
然后您在查询中变得聪明，这样如果用户为给定的下拉列表选择ALL，则会获得所有匹配的记录，并且插入的数据必须满足适当的参照完整性。成本中心必须属于有效站点。员工必须属于成本中心，并且可能有一个或多个与其链接的流程。
但是放入＆＃34; All＆＃34;占位符？如果你沿着这条路走下去，你就会为自己打开一个伤害管理伪关系与真实关系的世界敞开心扉。
答案 1 :(得分：0)
实际上，您在站点和成本中心之间存在两种关系（我只将其缩小到这两个实体）。两者都是可选的，必须定义其中一个。
第一个关系是（无问题）零到一个关系站点到成本中心（涵盖成本中心已知并为站点分配的情况）。
第二种关系包括案例，没有分配成本中心，成本必须“以某种方式分配”。 “ALL”可能意味着每个成本中心（比如说）获得相等的份额。
这种分为两种关系使数据库设计更加干净，但它不能解决主要问题，即查询关系。
问题出现在连接谓词中的 OR条件（追逐两条路径），这可能会导致次优性能。
因此，这是您设计的试金石，收集主要查询并检查它们对样本数据的执行情况。
攻击性能问题的一种可能方法是定义物化视图，将ALL关系扩展到每个成本中心（由@Michael提出），并且可以在新成本的情况下刷新中心定义，因此您无需手动处理此类更改。