Ecommerce - MongoDB Applied Design Patterns - page 87

LEFT LEFT JOIN JOIN eav AAS t2 OON t0 . entity = t2 . entity

LEFT LEFT JOIN JOIN eav AAS t3 OON t0 . entity = t3 . entity ;

And that's only bringing back four attributes! Another problem illustrated by this example is
that the queries quickly become difficult to create and maintain.

Avoid modeling product data altogether
In addition to all the approaches just outlined, some ecommerce solutions with relational data-
base systems skip relational modeling altogether, choosing instead to serialize all the product
data into a BLOB column. Although the schema is simple, this approach makes sorting and fil-
tering on any data embedded in the BLOB practically impossible.

The MongoDB answer

Because MongoDB is a nonrelational database, the data model for your product catalog can
benefit from this additional flexibility. The best models use a single MongoDB collection to
store all the product data, similar to the single-table inheritance model in Single-table inherit-
ance .

Unlike single-table inheritance, however, MongoDB's dynamic schema means that the indi-
vidual documents need not conform to the same rigid schema. As a result, each document
contains only the properties appropriate to the particular class of product it describes.

At the beginning of the document, a document-based schema should contain general product
information, to facilitate searches of the entire catalog. After the common fields, we'll add a
details subdocument that contains fields that vary between product types. Consider the fol-
lowing example document for an album product:

{

sku : "00e8da9b" ,
type : "Audio Album" ,
title : "A Love Supreme" ,
description : "by John Coltrane" ,
asin : "B0000A118M" ,

shipping : {
weight : 6 ,
dimensions : {
width : 10 ,
height : 10 ,
depth : 1