What is an efficient MongoDB schema design for a multilingual e-commerce site?

Question

I'm designing a multilingual e-commerce site. Products have different properties. Some properties are different for each language (like color), other properties are the same for all languages (like SKU). Properties are not predefined, for example cars have other properties than espresso machines.

I'd like to design the database schema such that:

1. Searching and representing all products from category x in language y is fast
2. The amount of duplicate data is low
3. I don't want to use files with translations

I'm thinking about using a schema like this:

{
 _id: ObjectID("5dd87bd8d77d094c458d2a33"),

 multi-lingual-properties: ["name", "description"],

 name: { en: "Super fast car",
         nl: "Hele snelle auto"},

 description: { en: "Buy this car",
                nl: "Koop deze auto"},

 price: 20000,

 sku: "SFC106X",

 categories: [ObjectID("4bd87bd8277d094c458d2a43")]
}

Is there a better alternative to this schema? What problems will I encounter when I use this schema?

Answer 1

Later than I expected, but here's what we're implementing now...

Background: Our system is supposed to be able to import product inventory from multiple ecommerce sites, so flexibility & i18n are important.

EAV model:

db.products.find()

{ "_id" : ObjectId("4e9bfb4b4403871c0f080000"), 
"name" : "some internal name", 
"sku" : "10001", 
"company" : { /* reference to another collection */ }, "price" : 99.99,
"attributes": { 
  "description": { "en": "english desc", "de": "deutsche Beschreibung" },
  "another_field": { "en": "something", "de": "etwas"}, 
  "non_i18n_field": { "*": xxx } 
 }
}

We also need metadata for attributes, which includes admin editing tips (what input forms to use) and i18n for names of the attributes. Example:

db.eav.attributes.find()

{ "_id" : ObjectId("127312318"), 
"code" : "description", 
"labels" : { "en" : "Description", "de": "Beschreibung" }, 
"type" : "text-long", 
"options" : [], 
"constraints" : [ ]
}

The idea is that attribute metadata will be quite large and won't get copied. Most of the time operations will be done using values of the (dynamic) attributes. If attribute metadata is necessary to display UI etc. it can be loaded & cached separately, and referenced by the attribute code.

So by default everything that's an attribute is i18n-enabled.

Queries for i18n-enabled-attributes are simple:

db.products.find({ attributes.description.en: "searched val" })

Non translated attributes may be a hassle though since they'd need special treatment in queries:

attributes.description.*

Not sure what we'll do with those attributes yet. E.g. numeric values don't require translation. Any thoughts on that are welcome.

We're still not using this structure though, so these are really pre-implementation ideas. I'm expecting more issues to surface while we start using this in practice, i.e. doing UI for CRUD operations etc.