数据库表是否可以包含多个主键？
是的，我在谈论RDBMS。
答案 0 :(得分：20)
表可以有：
除此之外，您可以拥有任意数量的唯一索引，这基本上会做同样的事情。
答案 1 :(得分：1)
关系表的主键唯一标识表中的每条记录。 因此，为了保持每条记录的唯一性，您不能拥有该表的多个主键。 它可以是保证唯一的普通属性（例如，每人不超过一条记录的表中的社会安全号），也可以由DBMS生成（例如全局唯一标识符或GUID，在Microsoft SQL Server中）。主键可以由单个属性或多个属性组合而成。
答案 2 :(得分：1)
是的，您可以拥有复合主键，即将两个字段作为主键。
答案 3 :(得分：1)
“首先，您必须了解实体关系设计方法的历史，并理解关系数据库管理系统（RDBMS）中的”关系“一词。”
我是否礼貌地建议你先让自己接受这些相同科目的教育，然后再导致其他人陷入有缺陷的信仰？我会回答下面两个最糟糕的愚蠢行为。
“根据关系方法学原则，每个实体应该只有一种方法来识别它。”
这是我听过的关于关系数据设计的最大废话。关系模型不会限制任何“实体”，因为您错误地称之为具有任何精确数量的键。任何“实体”可以具有任意数量的密钥，并且根据其使“行”唯一的特性的定义，EACH密钥是用于“识别”的任何目的的有效候选者。选择在某些上下文中使用的最有用/最合适的一个（例如，引用表中的外键）是一个设计问题，关系模型对这些事情没有任何说法。
“因此，”R“DBMS试图促进实体关系的建模。”
Codd的论文“大型共享数据库的约会关系模型”，标志着关系模型的诞生，早于E-R的发明已经有好几年了。所以说，关系模型试图促进ER概念的建模，完全是倒退的事情，而只是展示了你自己对自己答案中提到的“历史”的完全无知。
答案 4 :(得分：1)
简短的回答是肯定的。主键是候选键，原则上与任何其他候选键没有区别。广泛观察到的惯例是每个表的一个候选键被指定为“主要” - 意味着它对于数据库设计者或用户来说是“优选的”或具有某些特殊含义。然而，这只是惯例。它只是一个方便的标签，并提醒一个键的潜在意义。在实践中，所有密钥都可以用于相同的目的，而“主要”密钥在任何基本方面都不是特殊的或唯一的。
答案 5 :(得分：0)
这就是为什么它被称为主键，因为它是，主要是
答案 6 :(得分：-1)
首先，您必须了解实体关系设计方法的历史，以及理解关系数据库管理系统（RDBMS）中的“关系”一词。
为了定义实体的边界和要形成的关系，必须有一个唯一的句柄或唯一的句柄组合来识别实体的每个单个实例，然后在它们之间形成关系。
您还需要理解“识别”一词的含义/根，它将实体的每个实例的“身份”归零。 “身份”是一个数学术语，意思是“一个”或一个单一性。
根据关系方法学原则，每个实体应该只有一种且只有一种方法来识别它。因此，“R”DBMS试图促进实体关系的建模。请注意“实体/类”和“实体/类实例”之间的差异。
然而，RDBMS被广泛使用，并且主要是由那些对准确描绘E-R设计原则不太感兴趣的人。因此，我们经常在表中放置多个可能的实体定义，我称之为实体别名。反对身份别名，其中实体集的两个或多个实例隐藏在同一个键下，实体别名就像表
EmpProj([empId], empName, empAddr, projId, projLoc)
实际上有两个在同一个表下别名的实体集：
Emp([empId], empName, empAddr)
Proj([projId], projLoc, empId)
这就是规范化进入时 - 将这些实体分开。尽量我们可以做一个体面的设计规范化，计算机科学家可能没有像统计学家那样对信息有很好的看法。计算机科学家（在本次讨论中包括对ER设计具有良好知识的每个人）都会尽力创建一个清晰定义实体及其关系的模式。
然而，在分析数据库中的大量信息18个月后，统计学家开始看到出现的主要成分，由于主成分与计算机科学家感知实体边界的错位，其分析严重削弱。 / p>
这是备用唯一键适用的地方 - 由于主要组件在数据库中作为ghost-entities存在而识别实体的实例。
因此，表的主键是因为该表被认为是一个完美的实体，因为实体应该只有一个主键，无论是单数还是复合。
就统计学而言，即使数据库每个表只允许一个主键，替代的唯一键也是统计学家那些鬼实体的主键。这就是为什么有时你会被统计学家感到沮丧，他们似乎通过将数据下载到他们工作站/ PC的本地数据库中来完成双重工作。
总之，“R”DBMS制造商在每个表中仅允许一个主键的约束是他们相信他们知道信息如何表现并相信由于人口而导致的信息的主要成分不会发生变异的假装。随着时间的推移。
如果表中有多个唯一键，则表示一种或多种可能性