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

Question

[s_pyanov]

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

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

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

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

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

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

Буду рад за любую информацию.
Заранее спасибо!)

Comments

[Максим Федоров]

Тут пишут, что работают полиморфные связи
https://github.com/jinzhu/gorm/blob/master/README.md

Answer 1

[Алексей Черемисин]

На мой взгляд, архитектура хранения не очень правильная.
Делайте две коллекции. Одна для Категорий, вторая - для Товаров.
В Товар же добавьте поля: Бренд, Категория [array].

По характеристикам товара - у меня они, увы, не одинаковые, поэтому храню их в Товаре в виде массива объектов

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

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

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

Если совсем глубоко - сделано на эластике, но проблем с монгой быть не должно.

Answer 2

[yayashitoya]

1.модно(куда же без этого?!)

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

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

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

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

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

Храните все вместе.

Comments

[s_pyanov]

Я имел ввиду sql драйвер для работы именно с sql базами не поддерживает джоины.

[yayashitoya]

s_pyanov, простому драйверу SQL все равно.
С его точки зрения SQL - просто текст.

[Shamil_Fayzullin]

yayashitoya, добрый вечер! не могу реализовать rest-api используя ORM-reform, поделитесь пожалуйста примером!!!Буду очень признателен!!!