Question

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

这不是很方便，因为结果是id不是普通的string id，而是在DB中存储为二进制文件。谷歌搜索这似乎产生了大量的问题，如＆＃34;如何从bson id中获取字符串？＆＃34;，实际上在golang中有Hex()方法{ {1}}允许你获取字符串。

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

我的问题是：使用ObjectId vs bson.ObjectId ID有什么好处？如果我使用普通字符串ID存储我的string实体，是否会丢失任何重要内容？

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，并且没有基本未使用的索引。

回到你的基本问题，不使用ObjectIds就会失去一些东西：很多时候，不使用ObjectId是更好的选择。但是如果你使用它，请使用二进制形式。