我将使用名为ID的字段;整数主键。是否还要指定第二个唯一字段，以便能够在某些ID字段/关系混乱时重建表，还是不担心？
我正在使用自动增量整数，带有Sql-CE数据库。单个用户。
答案 0 :(得分：3)
如果您的表的语义需要它，那么根据您的需要添加许多唯一键。例如，如果在您的问题域中所有“Employee”实体都由Name唯一标识，那么Name应该具有唯一的索引或约束。如果可以有两个具有相同名称的员工，那么当然，该列上不应存在唯一性约束。
我现在有一个客户需要保持每个学年，每个会计年度的信息。他们需要在学校和年级列上结合使用唯一约束（或索引）。有时候这两个也是主键，但即使它们不是主要的，它们也是独一无二的。
答案 1 :(得分：1)
我真的不明白你添加第二个唯一ID字段的动机 - 为什么？你从中看到了什么好处？
您需要的是ID，它是唯一的，稳定的，能够清楚地标识每一行并且可以作为主键 - SQL中的INT IDENTITY服务器做得非常好。
我没有看到为每一行添加第二个唯一ID的任何意义或收获......
答案 2 :(得分：1)
每个表都有一个或多个候选键。选择一个作为主键;在其他约束上添加UNIQUE约束以强制语义正确性。如果某些事情“混乱”，它与能够重建表格无关。
您还应该在WHERE子句中出现的列上有索引，以便尽快访问。这些是应用程序/用例特定的。
我的意思是一个地址表。您可能有一个代理主键。您还可以使用zip，city，province，county等不同组合的索引来提高SELECT的效率。您可能还希望将street1 / stree2 / city / province / zip组合设置为UNIQUE。取决于您的业务问题。
答案 3 :(得分：1)
表必须具有尽可能多的密钥才能承受数据完整性。如果此实例中的“ID”表示代理键，则答案为是，您通常应该有一个自然键来确保正确规范化数据库中的唯一性 - 否则您可能会复制有意义的业务数据。如果您在自然键之前识别代理键，那么我认为您采用了一种有缺陷的设计方法。
选择键的良好标准是：熟悉，简单和稳定。只考虑可能存在的缺点和额外的复杂性，只有在您有充分理由的时间和地点，才能为您的模型添加代理键。
答案 4 :(得分：1)
为了备份而进行冗余可能是值得设计的。
但是，正如您的问题所示，大多数人都没有通过将冗余列加载到架构表中来实现它。这样做有很多开销，并且有很多失败模式，在主ID被搞砸的同时重复ID被搞砸了。
您可能最好设计一个历史表，以便在有限的时间内跟踪ID的历史记录。很多人将历史表设计为离线存储的临时区域，只有最近的历史记录保留在数据库中。除了您感兴趣的问题之外，这种历史还可以解决其他问题。