MongoDb 中的产品目录

Question

我决定将 mongo db 用于产品目录： mongo db 产品目录生态系统

嗨，我想将 mongdo db 用于产品目录，但我有疑问？我有一个销售 100 个类别的二手产品的网站，我所有的领域都是选择性手段，如果用户想销售车辆，他应该选择“bmw,toyota”之类的品牌，而不是指令

因此，为了将所有详细信息保存在一份文件中，如果 2 年或 3 年后丰田应该更改为 toyooota 并且我的记录超过 2000 万条，我也应该更新所有 toyota toyootas 是吗？所以更新命令对于该数据来说很昂贵，

所以另一种方式是它的键值在另一个集合中，比如 1:bmw 2:toyota

因此，在文档之间进行调整，如果有一天我们决定将 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

Babak，这是一个常见问题，很抱歉，它没有明确的答案；只是“这取决于您的用例。”

我建议阅读 Kristina Chodorow 的 MongoDB：权威指南。它有点过时了，但它的文档设计部分非常永恒。

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

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

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