在postgresql中，什么是mongo _id字段的最佳表示方式？

Question

Mongodb _id 字段被定义为：

ObjectId is a 12-byte BSON type, constructed using:

a 4-byte value representing the seconds since the Unix epoch,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.

在PostgreSQL中，最高效的表示该字段的方法是什么？

- Ski

---

UUID似乎是一个很好的选择 - 或者如果你不需要所有这些额外的“包袱”，只需使用通过序列填充的整数列。 - user330315

当您需要BSON时，请使用BSON：https://github.com/maciekgajewski/postgresbson - Frank Heikens

通常我使用char（24）并存储ObjectId的十六进制表示，然后添加CHECK约束以确保它具有正确的格式。至于“有效”的意义是什么？速度？空间？程序员时间？减少人数？我发现24个字符的十六进制表示法是最容易和友好的格式。根据您用于与PostgreSQL接口的内容，您可能无法轻松使用postgresbson。 - mu is too short

您是否正在寻找按照 MongoDB 语义创建 PostGres ids 的方法？ https://gist.github.com/jamarparris/6100413 - Shifa Khan

Answer 1

我使用了带有约束条件 CHECK decode(mongo_id::text, 'hex'::text) > '\x30'::bytea 的 char(24)。虽然此约束条件不检查 ObjectId 的完整性，但它只允许存储有效格式。这将 ObjectId 以纯文本形式存储，使值易于阅读。

另一个选项是为该列使用 bytea 类型，并将数据输入为 "\xOBJECT_ID"，其中 \x 将 OBJECT_ID 的文本形式转换为字节数组。这比使用 char(24) 占用更少的空间（如果你有数百万行可能会很重要），但以非二进制格式访问值需要使用例如 encode(mongo_id::bytea, 'hex')（可能会很繁琐）。

此外，某些平台（如 RedShift）可能会出现 bytea 数据类型的问题。

如果你需要轻松访问 ObjectId 中的元数据，则可以解析并单独存储它（例如，在 jsonb 列或每个相关属性的单独列中）。可能只有元数据中的“创建时间”部分是有趣的属性。

- Petrus Repo