postgresql 中面向未来的主键设计
过去我一直使用 auto_generate 或 Sequences 作为主键。在我正在开发的当前系统中，有可能最终必须对数据进行分区，而这在过去从未有过要求。知道我将来可能需要对数据进行分区，那么使用UUID进行PK而不是数据库内置序列有什么优势吗？如果是这样，是否有一种设计模式可以安全地生成相对较短的密钥（比如 6 个字符，而不是通常的长密钥 e6709870-5cbc-11df-a08a-0800200c9a66）？每个表 36^6 个键对于我能想象到的任何表来说都绰绰有余。
我将使用 URL 中的键，因此简洁性很重要。
I've always used either auto_generated or Sequences in the past for my primary keys. With the current system I'm working on there is the possibility of having to eventually partition the data which has never been a requirement in the past. Knowing that I may need to partition the data in the future, is there any advantage of using UUIDs for PKs instead of the database's built-in sequences? If so, is there a design pattern that can safely generate relatively short keys (say 6 characters instead of the usual long one e6709870-5cbc-11df-a08a-0800200c9a66)? 36^6 keys per-table is more than sufficient for any table I could imagine.
I will be using the keys in URLs so conciseness is important.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
没有模式可以将 128 位 UUID 减少到 6 个字符，因为信息会丢失。
几乎所有数据库都实施称为增量键的代理键策略。
Postgres 和 Informix 有序列号，MySql auto_increment，Oracle 提供序列生成器。对于你的情况，我认为使用整数 ID 是安全的。
请参阅这篇文章：选择主键：自然键还是代理键？进行讨论可用技术
There is no pattern to reduce a 128-Bit UUID to 6 chars, since information gets lost.
Almost all databases implement a surrogate key strategy called incremental keys.
Postgres and Informix have serials, MySql auto_increment, and Oracle offers sequence generators. In your case I think it would be safe to use integer IDs.
See this article: Choosing a Primary Key: Natural or Surrogate? for a discussion of availabe techniques
我不确定您计划使用什么类型的分区（这个？< /a>)，但我不明白为什么要改变主键设计？即使旧的分区表是“活动的”（即，您可以在任何分区表中插入行）， 在多个表之间共享序列。
I'm not sure what type of partition are you planning (this?), but I don't see why to change the primary key design? Even if the old partitioned tables are "alive" (i.e., you might insert rows in any partitioned table), there is no problem in sharing the sequence among several tables.