Was ist ein effizientes MongoDB-Schemadesign für eine mehrsprachige E-Commerce-Site?

9

Ich entwerfe eine mehrsprachige E-Commerce-Website. Produkte haben unterschiedliche Eigenschaften. Einige Eigenschaften sind für jede Sprache unterschiedlich (wie Farbe), andere Eigenschaften sind für alle Sprachen gleich (wie SKU). Eigenschaften sind nicht vordefiniert, Autos haben beispielsweise andere Eigenschaften als Espressomaschinen.

Ich möchte das Datenbankschema so gestalten, dass:

  1. Das Suchen und Darstellen aller Produkte der Kategorie x in der Sprache y ist schnell
  2. Die Anzahl der doppelten Daten ist gering
  3. Ich möchte keine Dateien mit Übersetzungen verwenden

Ich denke über ein Schema wie folgt nach:

%Vor%

Gibt es eine bessere Alternative zu diesem Schema? Auf welche Probleme werde ich stoßen, wenn ich dieses Schema verwende?

    
i.amniels 23.09.2011, 12:11
quelle

1 Antwort

5

Später als ich erwartet habe, aber hier ist was wir jetzt implementieren ...

Hintergrund: Unser System soll in der Lage sein, Produktinventar von mehreren E-Commerce-Sites zu importieren, also Flexibilität & amp; i18n sind wichtig.

EAV-Modell:

%Vor%

Wir benötigen auch Metadaten für Attribute, die Admin-Bearbeitungstipps enthalten (welche Eingabemasken zu verwenden sind) und i18n für Namen der Attribute. Beispiel:

%Vor%

Die Idee ist, dass Attribut-Metadaten ziemlich groß sind und nicht kopiert werden. Die meiste Zeit werden Operationen mit Werten der (dynamischen) Attribute durchgeführt. Wenn Attribut-Metadaten für die Anzeige von UI usw. benötigt werden, kann es geladen werden & amp; zwischengespeichert und durch den Attributcode referenziert.

Standardmäßig ist alles, was ein Attribut ist, i18n-fähig.

Abfragen für i18n-enabled-Attribute sind einfach:

db.products.find ({attributes.description.en: "gesuchter Wert"})

Nicht übersetzte Attribute können jedoch ein Problem darstellen, da sie in Abfragen eine spezielle Behandlung benötigen:

attributes.description. *

Ich bin mir nicht sicher, was wir mit diesen Attributen noch machen werden. Z.B. numerische Werte erfordern keine Übersetzung. Irgendwelche Gedanken dazu sind willkommen.

Wir verwenden diese Struktur jedoch immer noch nicht, also handelt es sich wirklich um Vorimplementierungsideen. Ich erwarte, dass mehr Probleme auftauchen, während wir anfangen, dies in der Praxis zu verwenden, d. H. Die Benutzeroberfläche für CRUD-Operationen usw. zu verwenden.

    
Jakub P. 17.10.2011, 10:14
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Konvertiert Titanium Mobile Javascript in nativen Java- oder Objective-C-kompilierten Code?