Co to jest wydajny schemat schematu MongoDB dla wielojęzycznej witryny e-commerce?

Question

Projektuję wielojęzyczną witrynę e-commerce. Produkty mają różne właściwości. Niektóre właściwości są różne dla każdego języka (np. Kolor), inne właściwości są takie same dla wszystkich języków (np. SKU). Właściwości nie są predefiniowane, na przykład samochody mają inne właściwości niż ekspresy do kawy.

Chciałbym zaprojektować schematu bazy danych takie, że:

1. Wyszukany i reprezentujących wszystkie produkty z kategorii X w języku y jest szybka
2. Kwota duplikatu danych jest niska
3. I don „t chcesz użyć plików z tłumaczeniami

myślę o użyciu schematu tak:

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

Czy istnieje lepsza alternatywa dla tego schematu? Jakie problemy napotkam, kiedy korzystam z tego schematu?

Answer 1

później niż się spodziewałem, ale oto co mamy do wykonania teraz ...

Wstęp: Nasz system ma być w stanie importować zapasów produktów z wielu witryn e-commerce, więc elastyczność & i18n są ważne.

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

Musimy również metadanych dla atrybutów, które zawiera wskazówki edycji administratora (formy, co wejściowe do użytkowania) oraz i18n dla nazwy z atrybutów. Przykład:

db.eav.attributes.find() 

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

Chodzi o to, że metadane atrybutów będą dość duże i nie zostaną skopiowane. Większość operacji czasu zostanie wykonana przy użyciu wartości atrybutów (dynamicznych). Jeśli metadane atrybutów są niezbędne do wyświetlenia interfejsu użytkownika, to można je załadować oddzielnie w pamięci podręcznej i odwoływać się do niego za pomocą kodu atrybutu.

Domyślnie wszystko, co jest atrybutem, jest włączone i18n.

Zapytania dla i18n-enabled-atrybutami są proste:

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

dla przetłumaczone atrybuty mogą być uciążliwe, choć od oni potrzebują specjalnego traktowania w zapytaniach:

attributes.description *

Nie wiem, co zrobimy z tymi atrybutami jeszcze.. Na przykład. wartości numeryczne nie wymagają tłumaczenia. Wszelkie przemyślenia na ten temat są mile widziane.

Nadal nie używamy tej struktury, więc są to naprawdę pomysły przedwdrożeniowe. Spodziewam się, że więcej problemów pojawi się na powierzchni, podczas gdy zaczniemy używać tego w praktyce, tj. Robiąc interfejs użytkownika dla operacji CRUD itd.