让我们看一个简单的“坏”示例:假设我有2个集合'person'和'address' . 并假设在'地址'我想存储与地址相关联的人的'_id' . 将这个“参考密钥”项存储为'address'集合中的ObjectId vs string是否有任何好处?
我觉得将它们存放为字符串应该不会受到伤害,但我没有在mongo工作很长时间,如果我按照这种模式不知道它是否会伤到路上 .
我在这里阅读帖子:Store _Id as object or string in MongoDB?并且它说ObjectId更快,如果你使用父集合中的ObjectId获取/更新(例如,使用person._id作为ObjectId获取/更新'person'集合),我认为它是真的,但是如果通过其他集合中的字符串id表示进行搜索(在我们的示例中,通过person._id作为字符串搜索地址集合),我找不到任何暗示相同的情况 .
非常感谢您的反馈 .
3 回答
无论性能如何,您都应该以与您引用的_id字段相同的格式存储“引用键” . 这意味着,如果您的推荐文件是:
然后你会把它称为:
如果您指向的文档有一个字符串作为ID,那么它看起来像:
然后你会把它称为:
除此之外,因为你在谈论人和地址,所以在两个文件中完全没有它们可能更有意义,而是嵌入文档:
至于使用
string
作为文档的id,在meteor collection中,您可以生成文档IDRandom.id()
为字符串或Meteor.Collection.ObjectID()
为ObjectId
.在这个讨论循环中,Mongodb string id vs ObjectId,这是一个很好的总结,
ObjectId Cons - 它是一个对象,在实践中操作起来有点困难 .
String Pros - 开发人员可以创建特定于域的_id拓扑
String Cons - 开发人员必须确保_ids的唯一性
以上所有这些信息都基于
meteor
框架 . 对于Mongodb,最好使用ObjectId
,原因在于您的问题中链接的问题 .将其存储为objectId是有益的 . 与使用24字节的字符串相比,ObjectId大小为12字节时速度更快 .
此外,您应该尝试对集合进行反规范化,这样您就不需要创建2个集合(与RDBMS相反) .
这样的事情一般可能更好:
但同样,这取决于您的用例 . 这有时可能不合适 .
希望有所帮助! :)