使用我的客户代码作为主键的利弊是什么？

Question

我正在为我的一个销售团队设计一个数据库。现在，目标是获取客户及其邮寄地址的主列表，但数据库最终会扩展以跟踪其他一些客户数据。所以，现在我只是在客户表上工作，但我想确保我遵循良好的规范化和效率准则，以防这件事超出了当前的预期。

目前，我们有大约 3,000 名客户。因此，我们有用于识别客户的客户代码。每个最多 20 个字符，是字母数字，并且对于每个客户始终是唯一的（Foo, Inc. 可能有 FOOINC 的客户代码，可能有 25 个子帐户，但只有一个 FOOINC 主实体。如果我们曾经与另一家名为 Foo Technologies Inc 的公司合作，我们会创建一个新代码，例如 FOOTECH 或其他东西）。

我不是 DBA，但过去设计了几个 DB，并且传统上使用 SQL 标识字段作为 PK。在这种情况下，我一直在考虑使用客户代码。这样做的利弊是什么？一方面，如果我有唯一标识符，那么使用唯一标识符作为 PK 似乎是合乎逻辑的，我就是这样做的。另一方面，我知道字符串 PK 比 int PK 慢——这个数据库肯定会增长，但它永远不会有数百万行。3,000 名客户的业务已经超过 7 年，因此我们甚至需要很长时间才能达到数万行。

我研究过这个问题，辩论通常以“这取决于数据”结束——所以请教我......在这种情况下，你在规划表格时会考虑什么？你会用什么来PK？无论如何，在那里粘贴自动递增的 INT 有什么好处？索引和插入记录有什么问题吗？

仅供参考，表格布局只需要以下内容：

-CustomerCode(nvarchar(20))
-CustomerName(nvarchar(50))
-Address1(nvarchar(50))
-Address2(nvarchar(50)) - nullable
-Address3(nvarchar(50)) - nullable
-ZipCode (nvarchar(9))

额外的问题 - 是否值得坚持使用 3NF 并制作一个单独的表来保存城市、州、邮政编码作为 PK 并与客户表建立关系？或者不用担心 3NF 并将城市/州保留在客户表中以避免某些连接？

谢谢您的帮助！如果您需要任何其他详细信息，请告诉我。

Answer 1

优点 - 这是自然的关键，它是有道理的，它可能会被搜索，我想？

缺点 - 默认行为（完全可以更改）是主键作为聚集索引。字母数字并不是最佳候选，因为插入可能会导致页面拆分，因为它们没有像标识列那样设置为不断增加的值。与字符数据（unicode 为 40+ 字节）相比，Int 标识列占用的空间更少（4 字节）。这会使您的其他索引更大，因为聚集键是它们的一部分。如果您改变了识别客户和制定客户代码的方式，这一切都会被打破 - 使用代理可以使您免受此类更改的影响。

在这种情况下，我倾向于优化插入性能，并且经常为聚集键和主键使用标识列。我真的很喜欢整数聚集索引。（现在我知道你的问题不是关于聚集索引，而是关于主键......你仍然可以选择其他一些列作为聚集索引并将其作为主键，你也可以对此施加唯一约束并对待将其作为自然键，但不将其设为主键）。

我至少会用唯一的约束对其进行索引，并将其视为自然键。我只是不知道您是否真的需要将其设为主键。

Kimberly Tripp 是一位值得信赖的资源，她在她的博客上对主键和（更多）集群键有很多话要说 - https://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-聚类键/

这只是我的意见 - YMMV。