我应该使用唯一字符串作为主键还是应该将其作为单独的自动增量 INT？ [复制]答案

【问题标题】：Should I use a unique string as a primary key or should I make it as a separate autoincrement INT? [duplicate]我应该使用唯一字符串作为主键还是应该将其作为单独的自动增量 INT？ [复制]
【发布时间】：2011-01-16 13:25:39
【问题描述】：

可能的重复：
Surrogate Vs. Natural/Business Keys
When not to use surrogate primary keys?

所以，我更喜欢将 INT 作为 AI 的主键。但是，这就是我考虑将唯一字符串作为主键的原因：我不必查询相关表来获取主键，因为我已经知道它了。

例如：
我有一个多对多的关系：

客户 - 订单 - 产品

假设我想添加一个新客户和一个新订单，并且我已经知道他们购买了什么。我必须对产品表进行查询以获取 INT，但如果我有作为主键的字符串（唯一），我不必进行查询（这对我来说似乎更干净，我不是谈论优化/运行时速度，根本没有）。

【问题讨论】：

这个问题已经被问过很多次了。只需搜索“代理”。我最好的选择：stackoverflow.com/questions/63090/…
这可以作为重复关闭，但它更具体一点，因为我在问哪个更适合多对多关系！

标签： sql database-design primary-key

【解决方案1】：

如果您不担心优化，主键的主要 2 个标准是：

独特性
恒定性（永不改变）

例如如果您的问题域是 - 并且将永远是 - 使得 2 个产品名称始终不同，并且没有产品会更改其名称（想想 Norton Antivirus -> Symantec Antivirus 的名称更改的简单示例），那么您可以使用产品名称作为唯一键。

这两个必须 100% 正确，不仅是今天，而且对于数据库的任何可预见的未来生命周期。

因此，强烈建议使用数字 ID，因为您可能并不总是能够预测此类事情 - 稍后更改数据库结构以获得产品 ID 当然比需要映射和查询中名称的 ID。

【讨论】：

检查和检查。我想知道是否有人这样做并希望他们没有这样做。
我有，一旦我的功能规范发生变化，以至于密钥需要变异，我就后悔了。史诗般的失败:)

【解决方案2】：

如果您可以保证您的 VARCHAR 字段确实是唯一的并且希望稳定（不会更改），那么您绝对可以将其用作主键而不会出现任何概念问题。

反对将其用作主键（或更重要的是：SQL Server 中的集群键）的唯一真正原因确实是基于性能的。更广泛和不同大小的集群键在许多方面都不是最理想的，它不仅会影响您的表及其集群索引，还会影响该表上的所有非集群索引。但是，如果这不是您关心的问题，那么再次使用 VARCHAR 作为主键就可以了。

【讨论】：

好吧，让我问这个……回到多对多的例子。因为我在复制数据/实际内容，这会被认为是坏事吗？我想因为它没有改变，所以它没有错……只是感觉不对。
是的，显然，如果您使用自然键（例如“真实”数据）作为键，当您在多对多表中使用这些键时，您将有一定的重复。这同样适用于代理 INT 键 - 它可能不那么明显并且不那么“烦人”。

【解决方案3】：

呃...两者在某种程度上都是正确的

您的逻辑模型和设计将使用唯一的字符串。这是自然键。
由于架构/性能的原因，实际实现可能会使用数字自动编号列（代理键）

【讨论】：

有道理，但不太可能。物理模型源自逻辑模型 - IME，逻辑模型中唯一未显示的列是外键。从自然键切换到人工键并不是简单的模型更改。
@OMG Ponies：如果您使用对象角色建模，那么设计将永远不会使用代理键。当您来实现它时，您将添加一个代理键。我认为要么你误解了我，要么我使用了错误的术语。
IME（Oracle Designer，SQL Server SSMS 不做逻辑模型），您确实在逻辑模型中定义了 pk，无论是自然的还是人为的。你在用什么做 SQL Server 的逻辑模型？
@OMG Ponies：我会使用类似 NORMA 的东西：orm.net sourceforge.net/projects/orm
看了一下，thx - 它类似于 Oracle 中的逻辑 ERD，但关键区别在于 ORM 中没有定义属性。 Oracle Designer 逻辑模型包括属性及其数据类型。