mgo - bson.ObjectId 与字符串 id

mgo - bson.ObjectId vs string id

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

这不是很方便,因为结果是 id 不是普通的 string id,而是以二进制形式存储在数据库中。谷歌搜索这似乎会产生大量问题,例如 "how do I get a string out of the bson id?",并且确实在 golang 中有 ObjectIdHex() 方法允许您获取字符串。

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

我的问题是:使用 bson.ObjectIdstring id 有什么好处?如果我用纯字符串 ID 存储我的 mongo 实体,我会丢失任何重要的东西吗?

正如评论中已经提到的那样,将 ObjectId 存储为十六进制字符串会使它所需的 space 加倍,如果您想提取其中一个值,则首先需要构造来自该字符串的 ObjectId。

但你误会了。 绝对 不需要为强制性 _id 字段使用 ObjectId。很多时候,我建议不要那样做。这是原因。

以一本书、关系和一些为简单起见而搁置的其他考虑因素为例:

{
  _id: ObjectId("56b0d36c23da2af0363abe37"),
  isbn: "978-3453056657",
  title: "Neuromancer",
  author: "William Gibson",
  language: "German"
}

现在,这里的 ObjectId 有什么用?实际上none。这将是一个几乎没有任何用处的索引,因为您永远不会通过这样的人工关键字来搜索您的图书数据库。它没有语义价值。对于已经 具有 全球唯一 ID – ISBN 的对象,这将是一个唯一 ID。

所以我们像这样简化我们的书文档:

{
  _id: "978-3453056657",
  title: "Neuromancer",
  author: "William Gibson",
  language: "German"
}

我们减小了文档的大小,利用了预先存在的全球唯一 ID,并且没有基本上未使用的索引。

回到您的基本问题,您是否因不使用 ObjectId 而失去了一些东西:通常,不使用 ObjectId 是更好的选择。但是如果你使用它,请使用二进制形式。