¿Qué es un diseño de esquema MongoDB eficiente para un sitio de comercio electrónico multilingüe?

Question

Estoy diseñando un sitio de comercio electrónico multilingüe. Los productos tienen diferentes propiedades. Algunas propiedades son diferentes para cada idioma (como el color), otras propiedades son las mismas para todos los idiomas (como SKU). Las propiedades no están predefinidas, por ejemplo, los automóviles tienen otras propiedades que las máquinas de espresso.

me gustaría diseñar el esquema de base de tal manera que:

1. Búsqueda y representación de todos los productos de la categoría X en el lenguaje y es rápido
2. La cantidad de datos duplicados es baja
3. Pongo 't desea utilizar archivos con traducciones

estoy pensando en usar un esquema como éste:

{ 
_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")] 
} 

¿Existe una mejor alternativa a este esquema? ¿Qué problemas encontraré cuando use este esquema?

Answer 1

tarde de lo que esperaba, pero esto es lo que estamos implementando ahora ...

Antecedentes: Nuestro sistema se supone que es capaz de importar inventario de productos a partir de múltiples sitios de comercio electrónico, por lo que la flexibilidad & i18n son importantes.

modelo EAV:

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 } 
} 
} 

También necesitamos metadatos de atributos, que incluye consejos de edición de administrador (formas de entrada a lo utilizan) y i18n para nombres de los atributos. Ejemplo:

db.eav.attributes.find() 

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

La idea es que los metadatos de los atributos serán bastante grandes y no se copiarán. La mayoría de las operaciones de tiempo se realizarán utilizando los valores de los atributos (dinámicos). Si los metadatos de los atributos son necesarios para mostrar la interfaz de usuario, etc., se pueden cargar & almacenados en caché por separado y a los que se hace referencia mediante el código de atributo.

De manera predeterminada, todo lo que es un atributo está habilitado para i18n.

consultas para i18n habilitados-atributos son simples:

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

no traducida atributos pueden ser una molestia, aunque ya que necesitarían un tratamiento especial en las consultas:

attributes.description *

No está seguro de lo que haremos con esos atributos todavía.. P.ej. los valores numéricos no requieren traducción. Cualquier idea sobre eso es bienvenida.

Todavía no estamos usando esta estructura, por lo que estas son realmente ideas previas a la implementación. Estoy esperando que surjan más problemas mientras comenzamos a usar esto en la práctica, es decir, haciendo UI para operaciones CRUD, etc.