mgo - bson.ObjectId vs string id [英] mgo - bson.ObjectId vs string id

问题描述

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

这不是很方便，因为它不是简单的字符串 id，而是将id存储为二进制数据库。谷歌搜索这似乎产生吨问题，如我怎么得到一个字符串的BBS ID？，并确实在 golang 有 （$ ObjectId ）的Hex（）方法来允许您获取字符串。

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

我的问题是：使用 bson.ObjectId vs string id？如果我使用纯字符串ID存储 mongo 实体，我会失去任何重要的东西吗？

解决方案

正如在注释中已经提到的那样，将ObjectId存储为十六进制字符串会使其所需的空间增加一倍，你想提取它的一个值，你首先需要从该字符串构造一个ObjectId。

但是你有一个误解。绝对完全不需要使用ObjectId作为强制 _id 字段。很多时候，我反对这个建议。这是为什么。

以书籍，关系和其他一些考虑事项为例：

  {
 _id：ObjectId（56b0d36c23da2af0363abe37），
 isbn：978-3453056657，
 title：Neuromancer，
作者：威廉吉布森，
语言：德语
} 
  

现在，在这里有什么用ObjectId？其实没有。这将是一个几乎没有任何用处的索引，因为你永远不会用这样的人造关键字搜索你的图书数据库。它没有语义价值。这是一个已经拥有全局唯一ID的对象的唯一标识符。

因此，我们简化了我们的书籍文档，就像这样：

  {
 _id：978-3453056657，
 title：Neuromancer，
作者：William Gibson，
语言：德语
} 
  

我们已经缩小了文档的大小，使用了先前存在的全球唯一ID并且没有基本上未使用的索引。

回到您的基本问题通过不使用ObjectId松散的东西：很多时候，不使用ObjectId是更好的选择。但是，如果您使用它，请使用二进制形式。

Using mgo, it seems that best practice is to set object ids to be bson.ObjectId.

This is not very convenient, as the result is that instead of a plain string id the id is stored as binary in the DB. Googling this seems to yield tons of questions like "how do I get a string out of the bson id?", and indeed in golang there is the Hex() method of the ObjectId to allow you to get the string.

The bson becomes even more annoying to work with when exporting data from mongo to another DB platform (this is the case when dealing with big data that is collected and you want to merge it with some properties from the back office mongo DB), this means a lot of pain (you need to transform the binary ObjectId to a string in order to join with the id in different platforms that do not use bson representation).

My question is: what are the benefits of using bson.ObjectId vs string id? Will I lose anything significant if I store my mongo entities with a plain string id?

解决方案

As was already mentioned in the comments, storing the ObjectId as a hex string would double the space needed for it and in case you want to extract one of its values, you'd first need to construct an ObjectId from that string.

But you have a misconception. There is absolutely no need to use an ObjectId for the mandatory _id field. Quite often, I advice against that. Here is why.

Take the simple example of a book, relations and some other considerations set aside for simplicty:

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

Now, what use would have the ObjectId here? Actually none. It would be an index with hardly any use, since you would never search your book databases by an artificial key like that. It holds no semantic value. It would be a unique ID for an object which already has a globally unique ID – the ISBN.

So we simplify our book document like this:

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

We have reduced the size of the document, make use of a preexisting globally unique ID and do not have a basically unused index.

Back to your basic question wether you loose something by not using ObjectIds: Quite often, not using the ObjectId is the better choice. But if you use it, use the binary form.

这篇关于mgo - bson.ObjectId vs string id的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！