@s_pyanov

Как выбрать способ хранения данных интернет магазина?

Всем доброго времени суток.
Нужно сделать интернет магазин обуви а аксессуаров.
Хочу использовать монгу, потому что:
1.модно(куда же без этого?!)
2.хочу попробовать именно её(потренироваться так сказать)
3.писать серверную часть буду на Го, а работать в го со сложными sql запросами практически не возможно(проблемы с проверками результата запросов - текущим го драйвером не поддерживаются join'ы и т.д.).

В связи с этим хочется разобраться, что бы не наступать на грабли: как лучше организовать структуру хранения данных о товаре/категориях?

Пару слов о том как каталог выглядит сейчас.
Данные о товаре хранятся в 1с(УТ). Они будут выгружаться в json файл. Далее нужно этот файл распарсить и загнать в монгу.

Структура номенклатуры такова:
Бренд 1
Коллекция1
...Товары...
Коллекция2
...Товары...
Бренд 2
Коллекция1
...Товары...
Коллекция2
...Товары...

Характеристики товара по идее должны быть одинаковые(цена, цвет, материал), но не у всех. Есть такие вещи как разные ростовки у разных поставщиков(маломерки/под отечественную ногу/европейские размеры и т.д.).

Есть идеи(подсмотрел где то), что нужно организовать документ с категориями:
{главная категория, дочерняя категория}
И каждому товару назначать соответствие, главная категория и дочерняя. Так ли это нужно делать?

Буду рад за любую информацию.
Заранее спасибо!)
  • Вопрос задан
  • 215 просмотров
Пригласить эксперта
Ответы на вопрос 2
leahch
@leahch
3D специалист. Dолго, Dорого, Dерьмово.
На мой взгляд, архитектура хранения не очень правильная.
Делайте две коллекции. Одна для Категорий, вторая - для Товаров.
В Товар же добавьте поля: Бренд, Категория [array].

По характеристикам товара - у меня они, увы, не одинаковые, поэтому храню их в Товаре в виде массива объектов
{ name: Сапог сложный
  sku: smart-shoozze-$Цвет$-$Размер$
....
Характеристики: [
{name: Цвет, value: Зеленый, type: checkboх, sku: GREEN},
{name: Цвет, value: Красный, type: checkboх, sku: RED}
]
....
}

Для вывода фильтров - делаете по этому полю агрегацию.

Если уж по существу - еще есть коллекция Остатки. А еще есть коллекция Медиафайлы.

Если совсем глубоко - сделано на эластике, но проблем с монгой быть не должно.
Ответ написан
Комментировать
@yayashitoya
1.модно(куда же без этого?!)

Преимущество Монги только в кластерах
https://www.youtube.com/watch?v=SNzOZKvFZ68

3.писать серверную часть буду на Го, а работать в го со сложными sql запросами практически не возможно(проблемы с проверками результата запросов - текущим го драйвером не поддерживаются join'ы и т.д.).


JOIN в Mongo вообще не поддерживаются нормально.
Это вам не реляционная СУБД.

Попробуйте ORM reform, а не стандартный драйвер Go.

В документарной СУБД какой является Монга - не производится разделение сущностей на таблицы (нормальная форма) так как в реляционных.

Храните все вместе.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы