django - UUIDField 与带有 UUID 的 Charfield 比较？

Question

所以我一直在 CharField 中使用 UUID 作为我正在从事的项目中的很多事情的 PK，工作正常，没有问题。如果我使用 UUIDField，后端中的某些内容将会出现 UUID 字段的问题(通常是期望 UUID 为字符串的函数)。

使用 UUIDField 与在 CharField 中仅使用“default=uuid.uuid4”相比有什么优势吗？

Answer 1

Is there any advantage of using a UUIDField vs just having default=uuid.uuid4 in a CharField?

是。

对于 postgresql 数据库，UUIDField 将使用 UUID type ^{[postgresql-doc]} ，这会将 UUID 存储为 128 位数量，这比将其存储为字符串更紧凑，字符串需要 32 位字节或 256 位(占用两倍的空间)。

如果您要使用 CharField(max_length=36, default=uuid.uuid4)，您甚至需要使用 36 个字符，因为 UUID 默认情况下会在 str 之间添加破折号，而不仅仅是使用十六进制值，因此会为这些破折号添加额外的四个字符，它们本质上是相同的，因此浪费更多存储空间。

但除此之外还有其他优点。事实上，它会强制 CharField 的长度为 32 个字符，并且格式(如果作为字符串传递)实际上是 UUID。因此，它将对格式进行正确的验证。

它还可以将多种格式的字符串解析为同一个UUID。例如 {12345678-1234-5678-1234-567812345678}、12345678123456781234567812345678 和 urn:uuid:12345678-1234-5678-1234-56 7812345678都将被解析为相同的值，如果您使用简单的 CharField，则不会出现这种情况，因为它会考虑这些不同的字符串。如果您这样工作:

MyModel.objects.filter(pk='urn:uuid:12345678-1234-5678-1234-567812345678')

它将检索具有该 UUID 的记录，即使该值以不同的格式存储在数据库中。

它从数据库检索的值包装在 UUID 类型中。这比字符串“更丰富”，并且可以防止出错。例如，添加两个 UUID 是没有意义的。确实:

>>> uuid4() + uuid4()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'UUID' and 'UUID'

而对于字符串，它将导致连接两个字符串。

此外，它还可以使用 UUIDField ^[Django-doc] 作为表单字段，这使得将不同的小部件挂接到此类字段更加方便，从而以不同的方式呈现表单。

因此，它提供了有关其期望的数据类型的更多上下文，通常更好的上下文意味着内省(introspection)模型的模块可以做得更好。