Комментарии 7
А есть какие-нибудь сравнительные оценки производительности MongoDB vs SQL EAV? Было бы здорово понять на сколько рационально с точки зрения производительности использовать базу без схемы
А можете поподробнее рассказать про продукт, скриншоты которого попадаются с статье? если это конечно не NDA.
Я так понимаю это некий бек-офис для сетевого ритейла?
Если имеются в виду скриншоты из первой части,
то это админка похожая на другие e-commerce решения, типа , SAP или adempiere.
Написано было для себя, Python/MongoDB/Jquery/bootstrap.
На github к сожалению пока не выложил из за отсутствия времени, но надеюсь что руки дойдут.
Самый лучший вариант — использовать одну коллекцию для хранения всех видов документов. И поскольку для каждого документа схема может быть любой, то можно хранить все имеющиеся у товара характеристики (атрибуты) в одном документе.

Нет, это не лучший вариант. Потому что ограничение в 50 индексов на коллекцию сильно ограничит возможности поиска разнообразных документов (вы же не хотите фуллсканом бегать по данным?) + ущерб производительности за счет большого кол-ва индексов.

Более правильно каждую категорию хранить в своей коллекции. Т.к. в Монге нет DDL, это почти не усложнит приложение.
т.е. имеется ввиду такая схема
{
  category_name: 'name',
  products:[
    {product: ...},
    {product: ...},
  ]
}

Как быть если продукт принадлежит разным категориям?
Здесь имеется ввиду категория не как тэг, а как схема документа «продукт».

И коллекцию лучше назвать по имени категории, а продукты в ней сделать документами первого уровня.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.