产品目录在MongoDb

Question

我决定将mongo db用于产品目录： mongo db product catalog ecosystem

您好我想使用mongdo db进行产品目录，但我有疑问？ 我有一个网站，可以销售100个类别的二手产品 并且我的所有领域都是选择性的意味着如果用户想要销售车辆，他应该选择像“宝马，丰田”而非指令这样的品牌

所以为了保存一份文件中的所有细节，如果在2年或3年后，丰田应该改为toyooota，而我的记录要记录2000万条记录，我应该更新所有的丰田太玩具，是吗？因此更新命令对于该数据来说是昂贵的，

另一种方式，它的关键值在另一个集合中 1：宝马 2：丰田

所以在文件之间做一个实现，如果有一天我们决定将toyota改为tooyoota，我们只改变1条记录而不是整个收藏？

所以你更喜欢大数据的大量更新， 或者在产品目录详细信息和另一个关键值集合之间建立关系 然后详细说明

{
  title:"a good vehicle" 
  details:{
  brand:"1" // means bmw, if we decide to change bmw name we should change   brand name in another collection

  }

}

另一种方式是

{
  title:"good vehicle",
   details:{
   brand:"bmw" // if one day we want to changes all bmw to bmwn for example, then we need a huge update
   }
}

注意：用户不能直接输入他们的品牌名称，例如ebay，

，这些价值是有选择性的 你喜欢mongodb中的这个设计吗？

Answer 1

巴巴克， 这是一个常见的问题，我很遗憾地说它没有明确的答案;只是“这取决于你的用例。”

我建议阅读Kristina Chodorow的MongoDB：The Definitive Guide。这有点过时了，但它的文档设计部分是相当永恒的。

以下是对普遍共识的简短解释：

1. 您的用例主要是查询吗？如果是这样，请嵌入您查询的字段。它将占用更多空间并使任何更新变得痛苦，但是数据库必须为大部分工作量增加的工作量将使每天都变得痛苦。
2. 您的用例主要是更新吗？如果是，则嵌入引用。这将使查询更容易更新。
3. 你的用例介于两者之间吗？然后做两者的组合。

请记住，MongoDB在很大程度上依赖于应用程序逻辑（程序员）来解决传统RDBMS解决的许多问题（模式实施，数据类型等）。您可以在应用程序本身解决许多问题。您提供的简单示例不是可能发生的事情，也可以在应用程序中轻松解决，无需在数据库中执行任何操作。我建议您认真考虑一下您每天需要做什么数据库，并使用它来推动您的文档设计或重新规划的决定。请记住，您推迟的每一天都会使您的问题更具影响力，更难以解决。