java - 我应该使用 "natural ID"创建实体还是应该始终在每个实体中使用 Long 作为 ID

Question

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

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

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

friend 们，你们认为哪种模型更好，为什么？

Answer 1

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

所以这个问题:

影响

• 在任何情况下，数字 ID 的查找速度都更快。但由于字符串也非常快(当使用适当的索引时)，这对于大多数应用程序来说可能已经足够了。
• 数字 ID 使用较少的空间(这通常是问题最少的)
• 在涉及异构系统的情况下，通常首选字符串 ID(您可以在示例中看到:服务提供带有字符串 ID 的“资源”)。原因之一是它更容易调试，例如用户可能一眼就能看出引用了什么对象，这是字符串是几乎所有系统最常见的分母的另一个原因(尽管编码问题仍然存在^^)。
• 如果您必须在数据库中执行大量手 Action 业，您可以更快地输入数字，因为字符串往往更长
• 如果您使用自然 ID，则很常见的情况是 ID 由多列组成。这使得 SQL 语句变得更长并且更容易出错，就像它使得对象关系映射器配置变得更长并且更容易出错一样。
• 您通常有一些唯一的标识符(例如电子邮件)，但可能会随着时间的推移而改变(人们结婚^^)。在这些情况下，添加一些人工 ID 也是很常见的(两者都有)

在您的情况下，除了使用该字符串 ID 与此服务进行通信之外，您别无选择(？)，因此您至少也必须有这个。

现在来说说我自己的看法:我认为作为一名开发人员，数字 ID 的工作量和问题也更少，尽管调试有点困难。作为一名数据库管理员，如果您只有一列，那么它是 String 还是 Long 并不重要，因为它不会使连接复杂化。只要字符串是不可变的，例如从未改变，你一切都好。如果它能改变的话，肯定会给作为管理员的你带来很多麻烦(而且愚蠢的开发人员也不会在意^^)。如果它可能随着时间的推移而改变，请使用数字 ID。