始终尽可能创建唯一键？

Question

您是否应始终尽可能创建唯一密钥？

例如，让我说我有一个包含三个字段的表，学生ID，名字，姓氏和学生ID是主键。

如果没有两个学生有第一个＆amp;姓氏，我应该为这两个字段创建一个唯一的密钥吗？

Answer 1

是的，通常拥有唯一ID（代理键）是最好的。在这种情况下，主键的姓氏和名字是不够的。即使你现在没有重复的名字，你也不能确定将来不会有两个John Smith。

Answer 2

不要假设没有两个学生会有相同的名字。

当底层模型建议时，创建唯一键是个好主意。像这样的约束将确保有凝聚力的数据并防止错误。但在你的情况下，基础模型并不表明情况就是这样。

Answer 3

唯一键应遵循业务定义;如果studentID是一个“半自然”密钥（它具有超出您特定数据库的独特含义），那么这应该足以作为您的唯一密钥。

如果studentID只是一个由数据库作为行号分配的标识值，那么您可能需要一些其他唯一密钥以避免两次输入同一个学生。

Answer 4

与数据域无关的原始主键是广泛接受的最佳实践之一 （想象一下 - 你的一个学生决定结婚）

另一个好习惯（尽管来自NoSql）世界是使用GUID - 这种方式键是唯一的，不同的数据集可以在同一个表中混合而不会发生冲突。

PS：你可以节省一些存储空间，但今天它很便宜而且没有必要为它牺牲好的做法

Answer 5

是的，即使在列或列组合是唯一的情况下已有主键时，也应使用唯一索引。在数据库中使用约束来防止错误数据是很好的。但是，这不是您的情况。即使您目前没有名称重复的学生将来也很容易发生。名称在世界上并不是唯一的。

U.S。社会安全号码几乎总是独一无二的（它们可以在多年后重复使用，但在您的情况下不太可能发生），因此它们可能成为唯一索引的良好候选者。如果你有非美国学生，那么你需要让这个专栏可以为空。

Answer 6

是！

如果您需要更新或删除表中的行，那么有一些东西可以唯一地标识表中的每一行。

以你的例子为例，我认为不能保证没有两个学生会分享同一个名字。即使添加出生日期仍然不能保证他们永远是独一无二的。我建议添加一个自动递增的INT或BIGINT作为主键。

您也可以随时添加唯一约束，如果它成为问题则将其删除。

Answer 7

一种简单的方法是使用自动生成的Guid（全球唯一标识符）来识别学生。每次产生它时，它都是“保证”的。名称可以改变（比如有人结婚），但是一些自动生成的值没有意义，所以永远不需要改变。

http://en.wikipedia.org/wiki/Globally_unique_identifier

Answer 8

您的数据库约束应该是DBMS理解的业务规则。是否有商业规则规定没有两个学生可能拥有相同的名字和姓氏组合？我认为不是，因此不要为这两个字段创建唯一的密钥。或许最好不要假设，并询问业务领域专家，例如招生官员。

请注意，此表中的一行是一个命题I.e.存在一名学生，其名字为'x'，姓氏为'y'，学生ID为'z'。显然，DBMS没有关于这个命题在现实世界中是否真实的概念。通常情况下会有一个可靠的来源来验证数据。企业将授权此职位的官员（董事等）。假设是注册官负责验证'x y'是真人，他们是否有资格注册，并且该人就是他们所说的人。通常，他们需要查看文件（证书，护照等），接受参考，与人交谈，检查公共记录等。当然，登记官员可以将他们的责任委托给其他员工或聘请代理人。

在某些时候，他们会感到满意，为方便起见，他们会发出自己的标识符，学生证。确实发生了错误，可能会发现这个值并不是唯一的，在这种情况下，登记官员有责任解决问题并向新学生发放。也许他们会使用软件来产生价值来缓解这些问题。学生证将发给学生，并将在企业内用于识别该人，以方便所有相关人员。甚至可以基于给定上下文中的信任级别（例如，可能需要产生照片ID以参加考试）向他们发放文档（例如照片ID卡）以帮助识别。如果学生忘记了他们的身份证，丢失了他们发行的文件等，那么登记办公室将能够从记录中检索它，例如参照验证过程中复制的文件;他们不太可能单独使用名字和姓氏。

关键是，标识符的可信来源是代表企业的注册官，而不是数据库，DBMS或该过程中涉及的任何其他类型的软件。因此，将学生ID作为数据库中支架的唯一标识符可能是可以接受的。但是，请考虑在企业内单个DBMS的一个硬件构建上生成的自动增量列可能不适合分配此类重要标识符值。