mgo-bson.ObjectId与字符串ID

一尘不染

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

这不是很方便，因为结果是stringID 代替了普通ID ，而是以二进制形式存储在DB中。谷歌搜索似乎会产生大量问题，例如“如何从bson
id中获取字符串？”，实际上，确实golang存在的Hex()方法ObjectId可以让您获取字符串。

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

我的问题是：使用bson.ObjectIdvs stringID有什么好处？如果我mongo使用纯字符串ID
存储我的实体，会不会有任何重大损失？

阅读 340

2020-07-02

共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是更好的选择。但是，如果使用它，请使用二进制形式。

2020-07-02