Каков эффективный дизайн схемы MongoDB для многоязычного сайта электронной коммерции?

Question

Я разрабатываю многоязычный сайт электронной коммерции.Продукты имеют разные свойства.Некоторые свойства различны для каждого языка (например, цвет), другие свойства одинаковы для всех языков (например, SKU).Свойства не определены заранее, например, автомобили имеют другие свойства, чем машины для приготовления эспрессо.

Я хотел бы разработать схему базы данных так, чтобы:

1. Поиск и представление всех продуктов из категории xна языке y это быстро
2. Количество повторяющихся данных мало
3. Я не хочу использовать файлы с переводами

Я думаю об использованиисхема такая:

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

Есть ли лучшая альтернатива этой схеме?С какими проблемами я столкнусь при использовании этой схемы?

Answer 1

Позже, чем я ожидал, но вот что мы реализуем сейчас ...

Справочная информация: Предполагается, что наша система способна импортировать товарные запасы с нескольких сайтов электронной торговли, поэтому гибкость и i18n важны.

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

Нам также нужны метаданные для атрибутов, которые включают советы по редактированию администратора (какие формы ввода использовать) и i18n для имен атрибутов,Пример:

db.eav.attributes.find()

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

Идея состоит в том, что метаданные атрибута будут довольно большими и не будут скопированы.Большинство операций времени будут выполняться с использованием значений (динамических) атрибутов.Если метаданные атрибута необходимы для отображения пользовательского интерфейса и т. Д., Они могут загружаться и кэшироваться отдельно, и на них может ссылаться код атрибута.

Таким образом, по умолчанию все, что является атрибутом, поддерживает i18n.

Запросы для атрибутов i18n-enabled:

db.products.find ({attribute.description.en: "search val"})

Непереведенные атрибуты могут быть хлопотными, поскольку они требуют особой обработки в запросах:

attribute.description. *

Не уверен, что мы будем делать с этими атрибутами еще.Например, числовые значения не требуют перевода.Любые мысли по этому поводу приветствуются.

Мы все еще не используем эту структуру, так что это действительно идеи перед внедрением.Я ожидаю появления новых проблем, пока мы начнем использовать это на практике, т. Е. Делать пользовательский интерфейс для операций CRUD и т. Д.