postgresql – 使用UUID或GUID作为主键有什么缺点？

发布时间：2020-12-13 16:23:41 所属栏目：百科来源：网络整理

导读：我想构建一个分布式系统.我需要将数据存储在数据库中,在某些表上使用 UUID或 GUID作为主键会很有帮助.我认为这是设计的一个缺点,因为UUID / GUID非常大,几乎是随机的.另一种方法是使用自动递增的INT或LONG. 使用UUID或GUID作为表的主键有什么缺点？我可能会

我想构建一个分布式系统.我需要将数据存储在数据库中,在某些表上使用 UUID或 GUID作为主键会很有帮助.我认为这是设计的一个缺点,因为UUID / GUID非常大,几乎是随机的.另一种方法是使用自动递增的INT或LONG.

使用UUID或GUID作为表的主键有什么缺点？

我可能会使用Derby / JavaDB(在客户端上)和PostgreSQL(在服务器上)作为DBMS.

这取决于您的生成函数和最终表的大小

GUID旨在成为全局唯一标识符.正如Postgres 8.3 documentation中所讨论的那样,没有一种方法可以普遍适用于生成这些标识符,但是postgreSQL确实附带了一些更有用的候选者.

从问题的范围和离线写入的需要来看,除了GUID之外,你已经非常巧妙地使用了任何东西,因此没有其他方案的补偿优势.

从功能的角度来看,密钥长度通常不是任何现代系统的问题,具体取决于读取的数量和表的大小.作为替代方法,脱机客户端可以在没有主键的情况下批量处理新记录,并在重新连接时简单地插入它们.由于postgreSQL提供“串行”数据类型,如果客户端可以执行对数据库的简单写入,则永远不需要确定ID.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!