Che cos'è un design efficiente dello schema MongoDB per un sito di e-commerce multilingue?

Question

Sto progettando un sito di e-commerce multilingue. I prodotti hanno proprietà diverse. Alcune proprietà sono diverse per ogni lingua (come il colore), altre proprietà sono le stesse per tutte le lingue (come SKU). Le proprietà non sono predefinite, ad esempio le auto hanno altre proprietà rispetto alle macchine per caffè espresso.

Mi piacerebbe progettare lo schema del database in modo tale che:

1. Ricerca e in rappresentanza di tutti i prodotti della categoria x in linguaggio y è veloce
2. La quantità di dati duplicati è basso
3. I don 't desidera utilizzare i file con le traduzioni

sto pensando di usare uno schema come questo:

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

Esiste un'alternativa migliore a questo schema? Quali problemi incontrerò quando utilizzo questo schema?

Answer 1

tardi di quanto mi aspettassi, ma qui è quello che stiamo attuazione ora ...

Background: Il nostro sistema dovrebbe essere in grado di importare inventario dei prodotti provenienti da più siti di ecommerce, quindi la flessibilità & i18n sono importanti.

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

Abbiamo anche bisogno di metadati per gli attributi, che include suggerimenti di modifica di amministrazione (forme quanto di alimentazione da utilizzare) e i18n per nomi degli attributi. Esempio:

db.eav.attributes.find() 

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

L'idea è che i metadati dell'attributo saranno piuttosto grandi e non verranno copiati. La maggior parte delle operazioni verranno eseguite utilizzando i valori degli attributi (dinamici). Se i metadati dell'attributo sono necessari per visualizzare l'interfaccia utente, ecc., È possibile caricarli separatamente nella cache & e fare riferimento al codice dell'attributo.

Quindi, per impostazione predefinita, tutto ciò che è un attributo è abilitato per i18n.

query per i18n-enabled-attributi sono semplici:

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

non tradotto attributi possono essere una seccatura se dal avrebbero bisogno di un trattamento speciale nelle query:

attributes.description *

Non so cosa faremo con quegli attributi ancora.. Per esempio. i valori numerici non richiedono la traduzione. Qualsiasi pensiero su questo è il benvenuto.

Tuttavia, non stiamo ancora utilizzando questa struttura, quindi queste sono idee di pre-implementazione. Mi aspetto che emergano altri problemi mentre usiamo questo in pratica, cioè facendo UI per le operazioni CRUD ecc.