在 MongoDB 中存储 ObjectId 与其字符串形式之间的区别 [英] Difference between storing an ObjectId and its string form, in MongoDB

问题描述

我对 Mongo DB 使用 ObjectIds 有点困惑.当然，它们非常适合在客户端创建 ID，几乎绝对不会与其他客户端创建的 ID 冲突.但是 mongo 似乎以某种特殊的方式存储它们.存储 id 的字符串表示与将对象 id 存储为对象不同.为什么是这样?

I'm a little confused by Mongo DB's use of ObjectIds. Sure they're great for creating IDs client-side that almost definitely don't conflict with other client-side created ids. But mongo seems to store them in some special way. Storing a string representation of the id is different from storing an object id as an object. Why is this?

字符串形式是否与对象形式具有相同的信息?为什么 mongo 如此费力地区分这两种形式?例如，当我尝试比较从前端发送的 _ids 时，它把我搞砸了.我的数据库与它是存储字符串形式的 id 还是对象形式的 id 完全不一致，虽然我的代码肯定有部分责任，我主要责怪 mongo 使这如此奇怪.

Doesn't the string form have all the same information that the object form has? Why does mongo go to such lengths to differentiate those two forms? It screws me up when I try to compare _ids sent from a frontend for example. My database is in no way consistent with whether it stores string-form ids or object-form ids, and tho my code is certainly partially to blame, I mostly blame mongo for making this so weird.

我错了，这很奇怪吗?为什么 mongo 这样做?

Am I wrong that this is weird? Why does mongo do it this way?

推荐答案

我个人责怪你的代码.通过以正确的方式编码，我在我的应用程序中完美地解决了这个问题.我在代码中转换为字符串进行比较，并确保任何看起来像 ObjectId 的东西实际上都用作 ObjectId.

I, personally, blame your code. I get around this pefectly fine in my applications by coding the right way. I convert to string in code to compare and I ensure that anything that looks like an ObjectId is actually used as a ObjectId.

值得注意的是，ObjectId (http://docs.mongodb.org/manual/reference/object-id/) 并且它的十六进制表示实际上有 12 个字节的差异，ObjectId 是 12 个字节，它的十六进制表示是 24.

It is good to note that between the ObjectId (http://docs.mongodb.org/manual/reference/object-id/) and it's hex representation there is in fact 12 bytes of difference, the ObjectId being 12 bytes and it's hex representation being 24.

不仅是存储效率，还有索引；不仅因为它们更小，还因为可以以特殊方式使用 ObjectId 以确保仅加载部分索引；使用的部件.这在插入时变得最明显，其中只需要加载该索引的最新部分以确保唯一性.您无法通过其十六进制表示来保证此类行为.

Not only is it about storage efficiency but also about indexes; not just because they are smaller but also since the ObjectId can be used in a special manner to ensure that only parts of the index are loaded; the parts that are used. This becomes most noticeable when inserting, where only the latest part of that index needs to be loaded in to ensure uniqueness. You cannot guarantee such behaviour with its hex representation.

我强烈建议您不要使用 OjbectId 的十六进制表示.如果你想让你的生活更轻松"，你最好创建一个不同的 _id ，它更小但不知何故唯一且索引友好.

I would strongly recommend you do not use the OjbectId's hex representation. If you want to "make your life easier" you would be better off creating a different _id which is smaller but somehow just as unique and index friendly.

这篇关于在 MongoDB 中存储 ObjectId 与其字符串形式之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！