MongoDB系列12：MongoDB电子商务产品目录模型设计
邓开表同学实战MongoDB系列文章，非常不错，赞！大力推荐！
本文是第12篇，主要讲述MongoDB电子商务产品目录模型设计实战操作，非常值得一看。
MongoDB系列文章：
MongoDB Compass--MongoDB DBA必备的管理工具
Change Streams构建实时同步数据流
电子商务的产品目录必须具有存储不同属性的许多不同类型的对象的能力。这些类型的数据集合与MongoDB的数据模型非常兼容。
对于关系型数据库，有几个解决这个问题的解决方案，每个解决方案都有不同的性能配置文件。以下讲述关系型数据库的几个解决方案以及MongoDB的解决方案。
1、关系型数据模型
1) 具体表继承
在关系模型中，一个解决方案就是为每个产品类别创建一个表。比如：视音产品类别；其中电影产品表product_film是视音产品类别的一个继承。
以下两个原因限制了模型的灵活性：
·必须为每个新类别的产品创建新表；
·必须为产品的类型关联所有查询；
2) 单表模型
这个模型使用所有产品类别的单个表，并在需要存储新产品类型的数据时添加新列。
这个模型比表继承更灵活，它允许单个查询跨越不同的产品类型，但是牺牲了空间。
3) 多重表继承
在关系模型中，可以使用多表继承模型表示通用的产品表中的共性，个别类型产品表中有一些变化。
多表继承比单表模型更具空间效率，比具体表继承更灵活一些。然而，该模型需要昂贵的连接操作来获得与产品相关的所有相关属性。
4) 实体属性值模型
关系建模的最终实体模式是实体属性值模式，可以理解为模型的元数据表，在其中创建产品数据的元模型。在这种方法中，只需要维护一个具有三列表，例如，entity(实体)，attribute(属性)，value(值)。
这个模式是完全灵活的：
·任何实体都可以有任何属性集合；
·新产品类别不需要对数据库中的数据模型进行任何更改；
缺点：所有非平凡查询都需要大量的连接操作，从而导致较大的性能损失。
2、非关系型数据模型
由于MongoDB是一个非关系型数据库，所以产品目录的数据模型可以从这种额外的灵活性中获益。最好的模型使用单个mongoDB集合来存储所有的产品数据，这类似于单表模型的关系模型。MongoDB的动态模式意味着每个文档不需要遵循相同的模式。因此，每个产品的文档只需要包含与该产品相关的属性。
模式
在文档的开头，架构必须包含一般的产品信息，以便于搜索整个目录。然后，包含在产品类型之间变化的字段的详细子文档。例如，一个视音产品示例如下：
对于一个电影产品有领域，一般的产品信息，航运和定价，但也有不同的细节子文档。如下：
小结：
在非关系模型中，MongoDB可以拥有多个值(即数组)的字段，而不需要对字段或值的数量进行任何限制(比如关系模型中的genre_0和genre_1)，也不需要连接操作。相比关系模型而言，这节省了昂贵的连接开销。
猜你喜欢
加入技术讨论群
《大数据和云计算技术》社区群人数已经3000+，欢迎大家加下面助手微信，拉大家进群，*交流。
喜欢QQ群的，可以扫描下面二维码：
欢迎大家通过二维码打赏支持技术社区（英雄请留名，社区感谢您，打赏次数超过108+）：