Ryan Lambert：Postgres中的UUID：PgSQLPhriday #015
内容提要
本文讨论了在Postgres中使用UUID的争议，作者倾向于使用BIGINT作为主键数据类型，因为它更方便查询和操作。除非涉及第三方系统，否则作者不会在生产系统中使用UUID。
延伸解读
开发者体验：BIGINT 的日常优势
作者强调，选择 BIGINT 主键的核心原因是日常查询和操作更简单。BIGINT 值如 1、2、983531 易于记忆、书写和复制粘贴，而 UUID 如 d556c9ac-dc30-4024-b0df-fd0e24e2596b 难以记忆，手写几乎不可能。在 VS Code 等编辑器中，双击 UUID 只会选中连字符之间的部分，而双击整数则选中整个值，这增加了操作摩擦。这种开发者体验的差异是作者避免使用 UUID 的主要理由。
生产环境中的 UUID 使用场景
作者明确表示，在生产系统中只在涉及第三方系统时使用 UUID。除此之外，他从未考虑过将 UUID 用于任何生产系统，并认为在许多情况下 UUID 带来了不必要的复杂性。他承认 UUID 有合理的用例，但在自己的领域中没有遇到，因此仍坚持使用 BIGINT。这反映了技术选型中务实的一面：根据实际工作流程和集成需求决定，而非盲目跟随趋势。
争议的本质与作者立场
文章指出，关于 UUID 的争论常被描述为数据库人员与开发者之间的分歧，但作者认为这种划分并不清晰，因为许多数据库人员也默认使用 UUID，而更多开发者选择自增 ID。争论的核心是表主键列的数据类型选择。作者创建表时使用 BIGINT IDENTITY 列作为主键，并默认使用 BIGINT 而非更小的 INT。他希望通过 PgSQLPhriday 听到支持 UUID 的观点，以了解不同场景下的合理用例。
Q&A
在Postgres中，主键应该用BIGINT还是UUID？
作者Ryan Lambert倾向于使用BIGINT作为主键，因为BIGINT值简单易用，方便查询和操作。UUID值复杂，难以记忆和操作，影响开发者体验。作者只在涉及第三方系统时才使用UUID。
为什么作者在生产系统中避免使用UUID？
作者避免使用UUID的主要原因是开发者体验差。BIGINT值易于记忆、书写和复制粘贴，而UUID值复杂，难以记忆和操作，增加了工作流程中的摩擦。作者认为UUID的复杂性没有必要。
在Postgres中如何生成UUID？
在Postgres中可以使用gen_random_uuid()函数生成UUID。此外，还可以使用uuid-ossp扩展来生成更多种类的UUID。
使用BIGINT作为主键有什么好处？
使用BIGINT作为主键的好处包括：值简单（如1, 2, 983531），易于记忆、书写和复制粘贴；在查询记录时更简单；双击即可选中整个值，方便复制粘贴。这些优点提升了开发者体验。
作者在什么情况下会使用UUID？
作者只在涉及第三方系统时才会在生产环境中使用UUID。在自己的领域中没有使用UUID的案例。
UUID和BIGINT在开发者体验上有何差异？
BIGINT值简单，易于记忆、书写和复制粘贴，双击可选中整个值。UUID值复杂（如d556c9ac-dc30-4024-b0df-fd0e24e2596b），难以记忆和书写，双击只选中部分（如破折号之间的部分），复制粘贴不便。这些差异影响了开发者体验。
