我应该使用“自然ID”创建实体，还是应该在每个实体中始终使用Long作为ID

Question

在我的职业生涯中，我看到了两种不同的设计，如何在DB中建模业务对象：

1. 始终使用Long作为实体的ID
2. 选择最合适的。

现在，我们有“资源”实体，我们可以从其他服务下载。每个资源都包含自然的ID - 电子邮件（电子邮件只是一个示例，我们可以想象当我们应该使用String时的其他情况）。我想将它用作数据库中的主要ID。但我的同事想要创建额外的属性 - Long id。我不确定，为什么要创建这个额外的属性。当然，DB模型更简单，因为所有实体都具有相同的结构，但我更喜欢使用String id。

你怎么看？伙计们，哪种模式更好，为什么？

Answer 1

我在校长中同意您应尽可能使用自然ID，但在这种情况下，电子邮件可能不是一个好的候选人。自然ID应该是不可变的，即它们永远不会改变。如果系统有可能需要更改/取消与资源的电子邮件关联，那么您实际上是在更改记录的标识。

如果是我，并且没有其他潜在的自然身份证;使用唯一的号码。在这种情况下，它不会增加任何不必要的复杂性，并使设计保持开放，以便将来更改电子邮件属性的需求。

Answer 2

首先，我不确定是否假设电子邮件可以是“资源”的唯一自然ID，因为这意味着每个新资源，您需要创建新电子邮件，资源无法读取电子邮件，但我知道情况，所以这可能是正确的。

所以问题是：

影响

• 在每种情况下，数字ID的查找速度都更快。但是，由于Strings的速度非常快（当使用适当的索引时），这对于大多数应用程序来说都足够了。
• 数字ID占用的空间较少（通常是问题最少）
• 在涉及异构系统的情况下，通常首选字符串ID（您可以在示例中看到：服务提供带有字符串ID的“资源”）。其中一个原因是它更容易调试，例如用户可能会看到一个对象被引用，另一个原因是Strings几乎是任何系统的最常见的分母（编码问题会在那里虽然^^）。
• 如果您必须在数据库中执行大量手动作业，则可以更快地键入数字，因为字符串往往更长
• 如果您使用自然ID，则很常见的情况是ID包含多个列。这使得SQL语句更长，更容易出错，就像它使对象关系映射器配置更长，更容易出错一样。
• 您通常会有一些唯一的标识符（如电子邮件），但可能会随着时间而变化（人们结婚^^）。在这些情况下，添加一些人工身份（同时具有两个）
是很常见的

在您的情况下，除了使用该字符串ID与此服务进行通信之外，您没有选择（？），因此您至少也必须拥有此服务。

现在对于我自己的观点：我认为作为开发人员，你可以减少工作量，减少数字ID的问题，尽管调试有点困难。作为数据库管理员，如果只有一列，则无论是String还是Long，都无关紧要，因为它不会使连接变得复杂。只要String是不可变的，例如永远不会改变，你很好。如果它可以改变它肯定会给你很多头痛的管理员（而愚蠢的开发人员不会在意^^）。如果它可能会随着时间的推移而改变，请使用数字ID。

Answer 3

米甲

电子邮件和此类字符数据列可能不是ID的正确选择，因为区分大小写取决于所使用的数据库实现和/或排序规则。您是否希望user@server.com和USER@SERVER.COM为您提供相同的结果？是否可能取决于您选择的数据库/操作系统/整理。如果您有基于字符数据的ID，则可以将这些问题从应用程序静默地推送到数据库管理＆amp;整理配置。

这可能很好，因为它只是一次性活动而您的数据库管理员可以为您设置它，但更多时候，您必须为不同的操作系统维护单独的数据库脚本。数据库。

在我看来，没有拇指规则，你必须根据情况做出最佳判断。

Answer 4

除了已经提到的参数之外，您还可以搜索“代理键”或访问维基百科关于此主题http://en.wikipedia.org/wiki/Surrogate_key的页面，其中列出了许多优缺点。