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

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

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

  1. поиск и представление всех продуктов из категории x на языке y быстро!--7-->
  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")]
}

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

9
database-design mongodb schema-design

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.товары.найти ({атрибуты.описание:.ru: "искал вал" })

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

атрибуты.описание:.*

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

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

6