PostgreSQL中UUID的完整指南

最新推荐文章于 2024-02-05 20:21:37 发布

寒冰屋

最新推荐文章于 2024-02-05 20:21:37 发布

阅读量9.1k

点赞数 1

分类专栏：数据库文章标签： PostgreSQ uuid

原文链接：https://www.codeproject.com/Articles/5298143/A-Complete-Guide-to-UUIDs-in-PostgreSQL

版权

数据库专栏收录该内容

212 篇文章 12 订阅

订阅专栏

使用uuid-osp创建UUID主键-PostgreSQL示例

更改大型关系数据库的架构每年会花费公司数百万美元。关系数据库高度交织，因此一个小的更改可能会产生意想不到的级联效应。

关系数据库中表的基础是主键。由于它的重要性，我们必须特别考虑如何选择主键。

在这篇文章中，我将讨论为什么主键是很重要的，不同的类型，您可以使用钥匙，并与保证值的主键有永远，永远在整个宇宙中（用1/10^37被使用出错的机会）。

理解SQL中的键

关系数据库已经存在近50年了。在最简单的形式中，关系数据模型是包含数据行的表的集合。这些数据库接收“关系”限定符，因为“相关”表通过键连接在一起。

SQL中有两种类型的键：主键和外键。

主键唯一标识表中的行。通过PRIMARYKEY在表中的特定列上放置约束，数据库引擎将保证不能输入与现有行具有相同键的行。在下一节中，我将介绍如何在Postgres中创建主键。

外键是第二个表中引用第一个表的主键的值。这种主/外键关系是将关系表联系在一起的粘合剂。

在上面的关系图中，Pets表中id是主键。该PetOwners表创建了一个外键pet_id，即引用id与Pets表中相同的值。因为这两个值是相同的，现在的Pets和PetOwners可以用连接join语句。

自然键与代理键

主键可以具有自然键值或代理键值。自然键与业务上下文相关联。例如，如果您使用狗品种作为Pets表的主键。

现在，这是不可取的，因为许多宠物可能是同一品种。

代理键是生成的唯一标识符，没有附加含义。我们在本文后面讨论的两个主键，UUID和自动递增，都属于这一类。在我们的Pets表中，代理键将是更好的选择，因为它保证是唯一的。

使用PostgreSQL创建主键的语法

创建表时定义主键：

CREATE TABLE PINK_FLOYD (
	id INTEGER PRIMARY KEY,
    album_name TEXT NOT NULL,
    release_date DATE NOT NULL…
);

在后台，Postgres通过结合UNIQUE和NOTNULL约束来实现主键。

创建复合主键

也可以通过组合两个（或多个）列来创建主键。在这种情况下，主键声明在CREATETABLE命令的底部，而不是顶部。

CREATE TABLE PINK_FLOYD (
	id INTEGER,
	album_name TEXT NOT NULL,
	release_date DATE NOT NULL,
	PRIMARY KEY (id, album_name,)
);

当您可以确定自然键的组合是唯一的时，这种类型的串联对于组织您的数据库很有用。

例如，如果您在一家非常小的公司工作，那么您可以使用员工名字和姓氏的组合作为主键。但是，这可能不适用于雇用多个John Smith的大公司。

主键保证同一表中每一行数据的唯一性。但是如果我们想要一个在表之间甚至数据库之间唯一的主键怎么办？

通用唯一ID？UUID介绍

UUID_v1示例

通用唯一标识符(UUID)于1990年由ApolloComputers首次推出。它们后来被开放软件基金会(OSF)标准化为一个ID，以保证“跨空间和时间的唯一性”。

UUID也称为GUID（全局唯一标识符），它来自Microsoft的名称。

UUID或GUID是128位值，表示为32个基数为16的数字。但是有不同的方法来生成这32位数字。

UUID_v4与UUID_V1

在UUID版本1(UUID_v1)中，这些值是由计算机系统使用当前时间和计算机MAC地址（如上例所示）的组合生成的。

或者，UUID_v4使用随机数生成器生成32个随机数字。这是最常用的UUID。

还有一个UUIDV5，但它不是随机的，所以你必须通过观察输入来确保它是唯一的。

使用uuid-osp创建UUID主键-PostgreSQL示例

安装SQL客户端

第一步是下载SQL客户端来运行您的SQL命令。

安装uuid-osp

首先，通过运行SELECT * FROM pg_extension.

如果uuid-ossp不在返回的列表中，首先您将运行make和makeinstall命令以从源发行版构建。make运行一个编译程序，并且make-install复制编译后的文件并将它们发送到您的位置。

现在我们可以通过运行来安装uuid-ossp模块：

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

将UUID添加到表——语法

假设我们想要创建一个表来存储PinkFloyd的所有专辑。以下就是我们如何使用uuid_generate_v4向该表添加UUID：

CREATE TABLE PINK_FLOYD (
	id uuid DEFAULT uuid_generate_v4 (),
	album_name VARCHAR NOT NULL,
	release_date DATE NOT NULL,
	PRIMARY KEY (id)
);

我们在底部声明主键，就像我们将两个表合并创建一个一样。

UUID的替代方案——自动递增主键

如果我们不需要在所有空间和时间中都是独一无二的怎么办？另一种类型的代理键是自增主键。

自动增量主键为每添加一个新行将键值增加1。MySQL使用AUTO_INCREMENT关键字，但在Postgres中，我们通过将数据类型设置为SERIAL来创建自动递增的键：

CREATE TABLE PINK_FLOYD (
	id SERIAL PRIMARY KEY,
	album_name TEXT NOT NULL,
	release_date DATE NOT NULL…
	PRIMARY KEY (id)
);

现在，每次你INSERT，Postgre都会为你的插入创建一个新的、自动递增的键。例如，如果您想为新专辑添加数据，则可以运行以下命令而无需在VALUES中指定id：

INSERT INTO PINK_FLOYD (album_name, release_date) VALUES ("The Wall", 1979-11-30);

UUID与自动递增主键

自动递增的主键提高了读取性能，因为它们比UUID更简单且扫描速度更快，但它们有一些主要缺点：

揭示潜在的敏感数据
跨数据库的重复键

自动递增的键显示您的表有多少行，您可能不希望该信息是公开的——有时您可能希望主键显示在您的URL中以保持它们的可靠性。

自动递增的主键也有可能跨数据库复制。这可能会导致分布式计算系统出现问题，该系统要求密钥在每个节点上都是唯一的。

但是UUID真的是独一无二的吗？

您可能会说好的，但是生成的UUID不能在表中创建相同的主键吗？由于UUID是随机生成的，这在技术上是可行的。

有可能，但概率极低。如果您有103万亿个版本-4 UUID，则找到重复项的概率是十亿分之一。以每秒1个UUID的速度计算，需要300万年才能达到103万亿个ID。

UUID足够惟一，或者几乎对每个用例都是如此，但是要存储的内容可能很多。如果您的表太大而无法一次性全部放入缓存中，如果您按UUID进行选择，则您的UUID可能会在缓存之外，从而减慢一切而不是仅仅移动到下一个ID。

那么我应该使用UUID吗？

如果安全是您最关心的问题并且您拥有大量存储空间，那么UUID是一个不错的策略。如果您有一个大型但相对未公开的数据库，您可能希望选择自动增量。

结论

总之，主键唯一标识表中的行。

您可以通过几种不同的方式创建主键，包括创建复合主键。

如果您想使用UUID，您需要在postgres中安装uuid-ossp，然后在您的CREATETABLE命令中包含您的UUID版本。

UUID有利也有弊——它们对安全非常有好处，尤其是当您的id在您的URL中时，但如果您的数据库很大，与自动递增的id相比，它们可能会减慢速度。

但是，您可以为独特性标上价格标签吗？前进并成为世界上其他人没有的128位数字的自豪拥有者！（大概）

https://www.codeproject.com/Articles/5298143/A-Complete-Guide-to-UUIDs-in-PostgreSQL

寒冰屋

关注

1
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
PostgreSQL中UUID的完整指南

目录理解SQL中的键自然键与代理键使用PostgreSQL创建主键的语法创建复合主键通用唯一ID？UUID介绍UUID_v4与UUID_V1使用uuid-osp创建UUID主键-PostgreSQL示例安装SQL客户端安装uuid-osp将UUID添加到表——语法UUID的替代方案——自动递增主键UUID与自动递增主键但是UUID真的是独一无二的吗？结论更改大型关系数据库的架构每年会花费公司数百万美元。关系数据库高度交织，因此一个小的更改可能会
复制链接

扫一扫