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

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

因此，问题来了：

影响

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

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

因此，现在我个人的观点是：我认为，作为开发人员，您的工作量更少，数字ID的问题也更少，尽管调试起来有些困难。作为数据库管理员，如果只有一列，则它是String还是Long都没有关系，因为它不会使连接复杂化。只要字符串是不可变的，例如永不更改，就可以了。如果它可以更改，那么肯定会给您带来很多管理员的麻烦（而愚蠢的开发人员不会在乎^^）。如果它可能随时间变化，请使用数字ID。