客户端生成的唯一 ID 与数据库唯一 ID

Question

对于分布式系统，建议从客户端生成唯一的 id。

这意味着如果我使用 PHP，那么将要持久化到 DB 中的实体的 ID 将在进入数据库之前具有其 ID。

这允许水平扩展基础架构，以及与您正在使用的数据库存储系统分离。

但是，如果我这样做并使用例如 uuid 库，则 ID 将是一个字符串，如果我有大表进行连接，则字符串 id 的性能会非常糟糕。

所以我的问题是推荐的方法是什么？我注意到像 Facebook 这样的公司使用整数 ID，它们似乎是前缀和后固定的。

那么这样做是否有意义：前 4 个字符是发起 id 的服务器，其他 15 个字符是随机 id + 最后 4 个字符是从 0000 到 9999 的随机数？

这种类型的模式/库有名字吗？

Answer 1

将业务信息塞进一个键是业务或自然键。任意键（随机、顺序等）称为代理键。我不太喜欢在 ID 中包含自然信息。请注意在数据库中使用自然键作为实际标识符的一些问题：

• 例如，如果您有独立或半独立的实体生成自己的内部唯一 ID，那么 ID 的特征可能会随着时间的推移而发生变化，并且可能不是所有独立实体同时发生变化，您可能会突然发现自己的版本 ID。
• 根据数据类型，实体可能会发生变化。例如，如果实体是国家，而国家一分为二或合并，那么您的 ID 空间会突然变得一团糟。
• 如果业务数据被更正或更改，您必须更改 ID 它在数据库中的任何地方使用。
• 不可避免地，当您使用数据库时，您会发现 ID 中没有的关键业务数据，并试图将其添加到您的密钥中。

在大多数情况下，我更喜欢将数据库生成的数字键 - 为简单起见，而不是性能 - 在表中作为代理键和带有自然键数据的边表。这使得添加新信息类型、处理自然数据中的变化、异常、错误、更改等变得更加容易。我发现很多（如果不是大部分）查询甚至不需要该人口统计信息。显然，当您与各种实体交互时，您会使用它们的 ID 空间。

此外，除非我遇到性能问题 - 这几乎总是索引问题或考虑不周的查询，而不是数据类型问题 - 我尝试以最合适的方式设置数据库并让数据库优化器执行他们的工作。