我过去一直使用 auto_generated 或 Sequences 作为我的主键。对于我正在使用的当前系统，有可能最终必须对数据进行分区，而这在过去从来都不是必需的。知道我以后可能需要对数据进行分区，那么使用UUID来进行PK，而不是数据库内置的sequence有什么优势吗？如果是这样，是否有一种设计模式可以安全地生成相对较短的 key (比如 6 个字符而不是通常的长 key e6709870-5cbc-11df-a08a-0800200c9a66)？每个表 36^6 个键对于我能想象的任何表来说都绰绰有余。
我将在 URL 中使用键，因此简洁很重要。
最佳答案
没有将 128 位 UUID 减少到 6 个字符的模式，因为信息会丢失。 几乎所有数据库都实现称为增量键的代理键策略。 Postgres 和 Informix 有 serials，MySql 有 auto_increment，而 Oracle 提供了序列生成器。对于您的情况，我认为使用整数 ID 是安全的。
请参阅本文:Choosing a Primary Key: Natural or Surrogate?用于讨论可用技术
关于postgresql - postgresql 中面向 future 的主键设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2808278/