mgo - bson.ObjectId 与字符串 id

Question

使用mgo，似乎最佳实践是将对象 ID 设置为bson.ObjectId。

这不是很方便，因为结果是stringid 以二进制形式存储在数据库中，而不是普通的 id。谷歌搜索这似乎产生吨的问题，如“我怎么得到一个字符串出BSON ID吗？”，而其实在golang存在Hex()的方法ObjectId，让你得到的字符串。

将数据从 mongo 导出到另一个数据库平台时，bson 变得更加烦人（在处理收集的大数据并且您希望将其与后台 mongo DB 中的某些属性合并时就是这种情况），这意味着很多痛苦（您需要将二进制 ObjectId 转换为字符串，以便在不使用 bson 表示的不同平台中加入 id）。

我的问题是：使用bson.ObjectIdvs stringid 有什么好处？如果我mongo使用纯字符串 id存储我的实体，我会丢失任何重要的东西吗？

Answer 1

正如评论中已经提到的，将 ObjectId 存储为十六进制字符串会使它所需的空间加倍，如果您想提取其中一个值，您首先需要从该字符串构造一个 ObjectId。但是你有一个误解。有绝对没有必要使用的ObjectId为强制性_id领域。很多时候，我建议不要这样做。这是为什么。举一个简单的例子，一本书、关系和其他一些为了简单而搁置的考虑因素：{  _id: ObjectId("56b0d36c23da2af0363abe37"),  isbn: "978-3453056657",  title: "Neuromancer",  author: "William Gibson",  language: "German"}现在，这里的 ObjectId 有什么用？其实没有。这将是一个几乎没有任何用处的索引，因为您永远不会通过这样的人工键来搜索您的图书数据库。它没有语义价值。对于已经具有全球唯一 ID（ISBN）的对象来说，这将是一个唯一 ID 。所以我们像这样简化我们的书籍文档：{  _id: "978-3453056657",  title: "Neuromancer",  author: "William Gibson",  language: "German"}我们减小了文档的大小，使用了预先存在的全局唯一 ID，并且没有基本上未使用的索引。回到您的基本问题，您是否会因为不使用 ObjectId 而丢失某些东西：通常，不使用 ObjectId 是更好的选择。但是如果你使用它，请使用二进制形式。