Amazon Web Services DynamoDB、MongoDB、Couchbase 和 MarkLogic 等 NoSQL 数据库，为存储产品目录信息提供了更优方案。
电子商务网站的产品信息存储与访问方式直接影响网站性能。无论规模大小，在线零售企业均可从 NoSQL 技术中受益。理解该技术前，需先认识产品信息描述的复杂性。
产品属性问题
多数电商平台将产品信息存储在关系数据库中，以类似电子表格的表形式保存。例如一件小型红色T恤，包含唯一ID、SKU、标题、尺寸和颜色五个属性，每个属性占据一列，一行代表完整产品信息。
| ID | SKU | 标题 | 尺寸 | 颜色 |
|---|---|---|---|---|
| 1 | POI0987654321 | 很棒的衬衫 | s | 红色 |
对于仅销售T恤的网站，此方法效果良好。若增加其他尺码和颜色的同款衬衫，只需在表中添加行即可。
| ID | SKU | 标题 | 尺寸 | 颜色 |
|---|---|---|---|---|
| 1 | POI0987654321 | 很棒的衬衫 | s | 红色 |
| 2 | POI0987654322 | 很棒的衬衫 | m | 红色 |
| 3 | POI0987654323 | 超赞T恤 | L | 红色 |
| 4 | POI0987654324 | 超赞T恤 | XL | 红色 |
| 5 | POI0987654325 | 超赞T恤 | S | 蓝色 |
| 6 | POI0987654326 | 超赞T恤 | M | 蓝色 |
| 7 | POI0987654327 | 超赞衬衫 | L | 蓝色 |
| 8 | POI0987654328 | 超赞衬衫 | XL | 蓝色 |
此类数据库查询编写简单且加载迅速。但若零售商扩展品类（如裤子），问题便会出现：裤子属性集不同，通常以腰围和裤长表示，而非小、中、大。
为解决该问题，可在表中新增列。
| ID | SKU | 类型 | 标题 | 尺码 | 腰围 | 内缝长 | 颜色 |
|---|---|---|---|---|---|---|---|
| 1 | POI0987654321 | 衬衫 | 很棒的衬衫 | s | 红色 | ||
| 2 | POI0987654322 | 衬衫 | 很棒的衬衫 | m | 红色 | ||
| 3 | POI0987654323 | 裤子 | Neat Pants | 30 | 30 | 黑色 | |
| 4 | POI0987654324 | 裤子 | Neat Pants | 30 | 31 | 黑色 |
此方案虽可行但难以扩展。若零售商持续增加产品类型：
- 腰带：需长度和材质属性；
- 帽子：需帽型属性（如按扣式或弹性式）；
- 鞋子：需鞋带长度和孔眼数量属性；
- 贴纸：需高度、宽度和粘合剂类型属性；
- 音乐：需艺术家属性及曲目列表存储方式；
- 电影：需导演、演员、评级、制作年份等属性。
此外，上述示例尚未包含价格、售价、成本、重量、运输尺寸等通用属性。很快，数据库表列数将达数百甚至数千，且多数列为空（如小号红T恤仅需约五列，其余均为空白）。这种单表方案托管成本高，严重浪费内存。
若为每种新产品类型分配独立表，可消除空间浪费：
| ID | SKU | 标题 | 尺寸 | 颜色 |
|---|---|---|---|---|
| 1 | POI0987654321 | 超赞衬衫 | S | 红色 |
| 2 | POI0987654322 | 超赞衬衫 | M | 红色 |
裤子信息则存入另一张独立表：
| ID | SKU | 标题 | 腰围 | 内长 | 颜色 |
|---|---|---|---|---|---|
| 3 | POI0987654323 | 整洁的裤子 | 30 | 30 | 黑色 |
| 4 | POI0987654324 | 整洁的裤子 | 30 | 31 | 黑色 |
该方案虽解决空间问题，但管理困难：每新增产品类型均需创建自定义表，平台需跟踪所有表及其关联关系。显示同一制造商的多类产品可能需多次数据库查询或“连接”（joins）操作。
第三种解决方案是实现实体-属性-值（EAV）系统，Magento 等主流电商平台即采用此法。EAV 通过多个表存储产品信息片段，以下为实体部分：
| 产品 ID | SKU | 标题 |
|---|---|---|
| 1 | POI0987654321 | 很棒的衬衫 |
| 2 | POI0987654322 | 很棒的衬衫 |
| 3 | POI0987654323 | Neat Pants |
| 4 | POI0987654324 | Neat Pants |
另设表存储单个属性的值：
| 产品ID | 属性 | 值 |
|---|---|---|
| 1 | 尺寸 | S |
| 1 | 颜色 | 红色 |
| 2 | 尺寸 | M |
| 2 | 颜色 | 红色 |
| 3 | 腰围 | 30 |
| 3 | 内缝长 | 30 |
| 3 | 颜色 | 黑色 |
| 4 | 腰围 | 30 |
| 4 | 内缝长 | 31 |
| 4 | 颜色 | 黑色 |
EAV 方案通常涉及三至五个以上独立表，可能导致产品信息访问速度较慢。尽管如此，对关系型数据库而言，它仍是管理产品目录的较优选择。
面向电子商务产品信息的 NoSQL
NoSQL（非关系型数据库）采用全新存储方式，摒弃结构化行列表格，以一致性换取可用性、速度与灵活性。尽管键值对数据库已存在数十年，NoSQL 近年才在 Google、Facebook、eBay 和 Amazon 等大型互联网企业中普及，以满足海量复杂信息的高速访问需求。
NoSQL 架构因实现而异，但核心原则是将项目所有数据存储于单一容器（项或文档）中。这些文档常以 JSON 格式存储，对 Web 开发人员极为友好。
电商产品在 NoSQL 中包含唯一 ID、通用属性及特有属性。例如小红衬衫可表示为：
{ unique_id: 'HY8765NBg6yYT77nBhNkln543NjNhYTR', sku: 'POI0987654321', type: ‘t-shirt’, title: 'Amazing Shirt', attributes: { size: 's', color: 'red' } }
特定裤子与衬衫共享部分结构，但拥有灵活的不同属性：
{ unique_id: '99iIiGtg6GHGjfj776098JjHGtgfffhhh', sku: 'POI0987654323', type: 'pants', title: 'Neat Pants', attributes: { waist: '30', inseam: '30', color: 'black' } }
零售商可销售任意产品类型，无需修改数据库表或追踪异构属性。腰带仅是数据库中的另一个容器：
{ unique_id: 'jjfJlkjsdfALKJljJLKDJ877KJNBB', sku: 'BE1888477', type: 'belt', title: 'Studded Belt', attributes: { size: '30', length: '30', color: 'black', material: 'leather' } }
NoSQL 显著提升灵活性，简化产品数据存储与管理，并加快单产品查询速度——产品数量越多，优势越明显。
NoSQL 考量因素
SaaS 电商平台可能无法利用 NoSQL，但使用许可电商平台或定制解决方案的零售商，可将 NoSQL 作为产品目录信息的更优选择。尽管关系数据库适用于多数场景，NoSQL 往往是产品信息管理的更佳方案。