MongoDB系列12：MongoDB電子商務產品目錄模型設計

鄧開表同窗實戰MongoDB系列文章，很是不錯，贊！大力推薦！

本文是第12篇，主要講述MongoDB電子商務產品目錄模型設計實戰操做，很是值得一看。

MongoDB系列文章：

MongoDB安全實戰之Kerberos認證

MongoDB Compass--MongoDB DBA必備的管理工具

MongoDB安全實戰之審計

MongoDB安全實戰之SSL協議加密

MongoDB安全實戰之網絡安全加固

MongoDB索引的介紹

MongoDB存儲引擎

MongoDB集合的增量更新

MongoDB數據遷移到MySQL

Change Streams構建實時同步數據流
Munin監控MongoDB

電子商務的產品目錄必須具備存儲不一樣屬性的許多不一樣類型的對象的能力。這些類型的數據集合與MongoDB的數據模型很是兼容。

對於關係型數據庫，有幾個解決這個問題的解決方案，每一個解決方案都有不一樣的性能配置文件。如下講述關係型數據庫的幾個解決方案以及MongoDB的解決方案。

一、關係型數據模型

1) 具體表繼承

在關係模型中，一個解決方案就是爲每一個產品類別建立一個表。好比：視音產品類別；其中電影產品表product_film是視音產品類別的一個繼承。

如下兩個緣由限制了模型的靈活性：

·必須爲每一個新類別的產品建立新表；

·必須爲產品的類型關聯全部查詢；

2) 單表模型

這個模型使用全部產品類別的單個表，並在須要存儲新產品類型的數據時添加新列。

這個模型比表繼承更靈活，它容許單個查詢跨越不一樣的產品類型，可是犧牲了空間。

3) 多重表繼承

在關係模型中，可使用多表繼承模型表示通用的產品表中的共性，個別類型產品表中有一些變化。

多表繼承比單表模型更具空間效率，比具體表繼承更靈活一些。然而，該模型須要昂貴的鏈接操做來得到與產品相關的全部相關屬性。

4) 實體屬性值模型

關係建模的最終實體模式是實體屬性值模式，能夠理解爲模型的元數據表，在其中建立產品數據的元模型。在這種方法中，只須要維護一個具備三列表，例如，entity(實體)，attribute(屬性)，value(值)。

這個模式是徹底靈活的：

·任何實體均可以有任何屬性集合；

·新產品類別不須要對數據庫中的數據模型進行任何更改；

缺點：全部非平凡查詢都須要大量的鏈接操做，從而致使較大的性能損失。

二、非關係型數據模型

因爲MongoDB是一個非關係型數據庫，因此產品目錄的數據模型能夠從這種額外的靈活性中獲益。最好的模型使用單個mongoDB集合來存儲全部的產品數據，這相似於單表模型的關係模型。MongoDB的動態模式意味着每一個文檔不須要遵循相同的模式。所以，每一個產品的文檔只須要包含與該產品相關的屬性。

模式

在文檔的開頭，架構必須包含通常的產品信息，以便於搜索整個目錄。而後，包含在產品類型之間變化的字段的詳細子文檔。例如，一個視音產品示例以下：

對於一個電影產品有領域，通常的產品信息，航運和訂價，但也有不一樣的細節子文檔。以下：

小結：

在非關係模型中，MongoDB能夠擁有多個值(即數組)的字段，而不須要對字段或值的數量進行任何限制(好比關係模型中的genre_0和genre_1)，也不須要鏈接操做。相比關係模型而言，這節省了昂貴的鏈接開銷。