Database design 重新启动主键以识别员工

我们公司决定在员工编号前加一个“X”来指定承包商。但他们并不是在所有系统中都这样做

---

这是一件危险的事情吗？为什么？我认为这完全取决于你如何实施它。我宁愿给他们正确的数字，然后创建一个新表，用数字作为外键，并用一行说明他是否是承包商。

如果不了解他们的系统，我会说这是一个糟糕的设计

• 如果他们想查找一名员工，但他们只有员工编号，但不知道该员工是否是承包商，那么他们必须检查是否有X
• 数据库可能允许承包商和非承包商使用相同的员工编号，因为唯一的约束将允许它
• 加入替换（员工，'X'，''）将起作用，但效率低下

更好的选择是为承包商创建一个可以为0或1的列。我想可能有一些原因阻止他们这样做（例如，无法更改的遗留系统）。

这是否“危险”是一个有点复杂的问题。如果你这样做的话，人们会死是值得怀疑的，但是，我绝对不建议这样做。从根本上说，作为数据库设计者，您的首要目标之一应该是数据完整性，这意味着每个数据值都有一个单一的含义。当我的客户建议这样做时，我告诉他们一个常见的说法是“我不能列出做

可能会发生的每一件坏事，但我可以说这很可能会产生问题”。在这种情况下，这种糟糕的做法是试图在一个值上赋予多个含义

其他人提到了您可能会遇到的一些问题。我还知道其他几个：

验证员工编号。您必须更改对员工编号的验证（您验证是否正确？），以忽略前导字符，但前提是它是一个“X”

向员工/承包商报告/输出。任何显示员工编号的报告都需要删除“X”

---

在国际海事组织，一个更好的解决方案是添加一个列，指明员工或承包商在公司中的角色

非常糟糕的想法。首先，出于性能原因，如果可能的话，PKs不应该是除数字以外的任何东西。第二，因为现在是字符串数据排序，所以将使用字符串排序和数字排序。这真的会让人恼火，因为121将跟随12而不是13

这项计划的另一个困难是，承包商有时成为雇员。您不想因为他的id号已更改而必须更改所有相关表

如果有人想用X来显示编号，那么如果有人是或不是承包商，则使用位字段在数据库中进行标记，使用自动编号字段获取员工编号，并在查询中使用案例语句将显示屏上的122更改为X122（如果该人是承包商）

---

进一步的绩效将受到影响，因为您无法使用自动生成的编号获取员工编号，这几乎是一个错误，因为现在您必须担心竞争条件。

以这种方式识别承包商的目的是什么？如果贵公司的工资单和人力资源系统没有更好的方式记录这些信息，那么我认为这些系统存在缺陷，应该予以修复或更换。

最好添加一个新的表格，列出具有日期范围的顾问/联系人。

如果表格无法修改，您可以添加一个额外的承包商查找表格（仍然不是理想的设计）只包含员工编号。