Question

我想设计产品之间的架构关系有多个类别你的选择性能（读，写）更好。

架构1 :: 2集合，带category_id数组的引用


    Collection Category {  id ,   name }
    Collection Product  {  id ,   name , category_ids: [category_id_1,category_id_2] }

架构2 :: 3集合，带新集合的参考


    Collection Category {  id ,   name }
    Collection Product  {  id ,   name }
    Collection product_category  {  id , product_id, category_id }

架构3 :: 2集合，带有嵌入集合的参考


    Collection Category {  id ,   name }
    Collection Product  {  id ,   name , 
      category_ids: {
          {id, category_id_1}
          {id, category_id_2}
          {id, category_id_3}
      }
    }

非常感谢。

Answer 1

Thumb规则是在使用MongoDB和一般NoSQL时使用非规范化（？）。因此，如果你不能（或不能）使用单一集合，最好使用两个集合。

背后的原因是MongoDB没有提供事务（尚未），原因似乎是扩展性较小。但它确实提供了原子更新，因此单个集合对于操作是安全的。

因此，3个集合中的选项2不是一个好的（读得非常糟糕）的想法。

看起来类别数据不像产品数据那样经常变化，所以我认为第一个选项比第三个选项更有意义。

如果您在category_ids字段上使用多键索引，那么在第一个选项中还有一件事情，这对于更快的访问是有益的。如果您对第三个选项上的category_ids使用索引，那将不会有用，因为对象的索引在数组上效率不高。

您在第三个选项中获得的一个好处是您可以为每个category_id保留一些产品的关联数据。

如果这是一件不想丢失的事情，那么你可以使用一个对象数组。

选项4：

Collection Category {  id ,   name }
Collection Product  {  id ,   name , 
  category_ids: [
      {id : category_id_1, limit : 10}
      {id : category_id_2, limit : 20 }
      {id :category_id_3, limit : 15 }
  ]
}

在这种情况下，我们可以将每个产品关联的限制因子与每个类别相关联。

但是，通过避免将RDBMS的最佳实践纳入NoSql来帮助自己。

Answer 2

如果我有10,000,000条产品记录

如果我选择你的选项4：


    Collection Category {  id ,   name }
    Collection Product  {  id ,   name , 
      category_ids: [
          {id : category_id_1, limit : 10}
          {id : category_id_2, limit : 20 }
          {id :category_id_3, limit : 15 }
      ]
    }

按category_id搜索产品

我认为这个选择是读取性能不好
因为mongodb通过category_id查找“Collection Product”上的所有文档。

如果我选择选项2，我想通过category_id

搜索product_id


    Collection Category {  id ,   name }
    Collection Product  {  id ,   name }
    Collection product_category  {  id , product_id, category_id }

我通过category_id搜索“Collection product_category”中的产品。
我有产品ID列表
我通过product_ids

或者这个选择更好。

感谢。

如何设计架构更好，产品与类别的关系

2 个答案: