小编Ren*_*aro的帖子

语境

我正在设计一个数据库（在 PostgreSQL 9.6 上），它将存储来自分布式应用程序的数据。由于应用程序的分布式特性，SERIAL由于潜在的竞争条件，我不能使用自动递增整数 ( ) 作为我的主键。

自然的解决方案是使用 UUID，或全局唯一标识符。Postgres 带有一个内置的UUIDtype，非常适合。

我对 UUID 的问题与调试有关：它是一个非人类友好的字符串。标识符ff53e96d-5fd7-4450-bc99-111b91875ec5什么也没告诉我，而ACC-f8kJd9xKCd，虽然不能保证是唯一的，但告诉我我正在处理一个ACC对象。

从编程的角度来看，调试与几个不同对象相关的应用程序查询是很常见的。假设程序员错误地ACC在ORD（订单）表中搜索（帐户）对象。使用人类可读的标识符，程序员可以立即识别问题，而在使用 UUID 时，他会花一些时间找出问题所在。

我不需要 UUID 的“保证”唯一性；我确实需要一些空间来生成没有冲突的密钥，但 UUID 有点矫枉过正。此外，最坏的情况是，如果发生冲突（数据库拒绝它并且应用程序可以恢复），也不会是世界末日。因此，权衡考虑，一个更小但对人友好的标识符将是我的用例的理想解决方案。

识别应用对象

我想出的标识符具有以下格式：{domain}-{string}，其中{domain}替换为对象域（帐户，订单，产品）并且{string}是随机生成的字符串。在某些情况下，{sub-domain}在随机字符串之前插入一个甚至可能是有意义的。让我们忽略的长度{domain}，并{string}为保证唯一性的目的。

如果有助于索引/查询性能，格式可以具有固定大小。

问题

知道：

• 我想要具有类似ACC-f8kJd9xKCd.
• 这些主键将是几个表的一部分。
• 所有这些键都将用于 6NF 数据库上的多个连接/关系。
• 大多数表将具有中到大的大小（平均约 1M 行；最大的表具有约 100M 行）。

关于性能，存储此密钥的最佳方法是什么？

以下是四种可能的解决方案，但由于我对数据库的经验很少，我不确定哪个（如果有）是最好的。

考虑的解决方案

1. 存储为字符串 ( VARCHAR)

（Postgres 在CHAR(n) …