【发布时间】:2021-03-27 15:01:57
【问题描述】:
这个问题已被问过几次,但使用 ObjectId 的“优点”似乎都不适用于我的案例,而且这些问题都已经很老了。我想知道我是否缺少任何东西。
具体来说,我在这两个选项之间做出决定:
- 将
_id存储为数据库中的ObjectId。 - 将
_id存储为 DB 中 ObjectId 的字符串表示形式。
我对倾向于存储 ObjectId 对象而不是其字符串表示的原因的理解:
- 它们是 12 字节而不是 24 字节。这只是每百万条记录 12 MB,文档大小的一小部分,以及几美分的额外基础设施,因此不保证增加我的应用程序代码的复杂性。
- 它们“更快”。我一直听到这个,但没有人说 多少 快,这让我想知道是否没有区别,每个人都只是重复他们从其他人那里听到的内容。我找到了these benchmarks,其中单个项目的读取时间是相同的。写一百万条记录时会有所不同,但我不会那样做。像这样的基准测试也没有考虑到每次写入操作将对象(通过网络)从字符串 ID 转换为
ObjectId对象所花费的额外时间。我怀疑必须在应用服务器上添加一个循环来解析传入数据并将字符串转换为new ObjectId(item._id)以获取百万条记录会平衡结果。 - 使用
ObjectId是“正常”的方式。我对这个论点有些动摇,我不喜欢以奇怪的方式做事。但由于它会导致额外的代码容易出现错误,因此这本身并不是一个足够好的理由。
想要执行选项 2 的原因是,当数据在用户空间和数据库之间流动时,我在应用程序的许多地方都在转换字符串/ObjectId。不仅适用于_id 字段,还适用于otherItemId 和listOfRelatedThingIds。它们都在输出时(通过网络)隐式转换为字符串,并且需要在输入时手动转换回来。这不是世界上最糟糕的事情,但如果没有充分的理由要这样做,那么我将切换到数据库中的字符串。
【问题讨论】:
-
我认为这个问题毫无意义。但是您可以讨论使用 MongoDB 内部的
ObjectId还是为_id字段使用自行开发的自定义字符串/数字是否有意义。 -
感谢您让我知道您认为我的问题毫无意义。现在如果有人问,Wernfried Domscheit 对此有何看法,我会毫不犹豫地说:“哦,Wernfried 认为这个问题毫无意义”
-
好吧,这个问题本身并不是毫无意义的。但是为 ObjectId 使用字符串的方法没有多大意义。