У юзеров, заказов, товаров довольно чёткая структура, и они отлично ложатся на реляционную базу

Монга предназначена для неструктурированных данных

в чем минусы?

А в чем плюсы?

я думал удобно будет в заказ ложить сразу все товары и возможно историю

как бы джоины особо не нужны тогда

в магазин ложить все товары

Сразу все товары, чтобы не создавать промежуточную таблицу?

можно еще будет видеть в случае изменения позиции что было в момент заказа

А количество ты где хранить будешь?

там же

Я не совсем понял, но допустим, а юзеры?

думал заказы в юзера положить, но там по месту ограничение

большое правда, но все равно

А сами товары?

и запросы простые все равно, реляция заказа только на юзера и магазин

ну иваще охота позырить что монго умеет, последний раз ее трогал года 4 назад )

А, ок

Тогда делай, я за то, чтобы учиться за счет работодателя

в заказе будут дублироваться товары

Не не, там можно в референсы

это инет магазин еды, поэтому, думаю позиции могут меняться довольно часто

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

чтобы не париться с возможным изменением позиций положить все в заказ, ненормально конечно

это инет магазин еды, поэтому, думаю позиции могут меняться довольно часто

Каких-то 200 тысяч позиций обновлялись 4 часа каждую ночь, вместо 5 минут в постгрессе

они же хвастаются что быстрее постгре

Каких-то 200 тысяч позиций обновлялись 4 часа каждую ночь, вместо 5 минут в постгрессе

может виноват не mongo, а архитектура? забыли какой-то ключь, что-то не правильно сделали.

может виноват не mongo, а архитектура? забыли какой-то ключь, что-то не правильно сделали.

Скорее всего, а ты считаешь, что монга подходит для инет магазина?

Скорее всего, а ты считаешь, что монга подходит для инет магазина?

у меня нет мнения на этот счёт. потому что я не работал с mongo. Но 200 000 элементов это смешной объем данных.

Крайне смешной, вся идея автора заключалась в возможности хранить пропертисы неструктурированные

Типа много разных категорий с абсолютно разными свойствами

А когда стало очевидно, что по ним нужно не только фильтровать, но и их выбирать начали появляться референсы

Потом появились категории, и опять референсы, чтоб не дублировать данные

Потом в заказ стало очевидным, что не сам продукт кладётся, а реф, количество, указание на ближ склад, цена на момент заказа, то чего kolas хочет избежать

мне кажется монго это не про нормализацию

денормализированные данные это норма там )

Мап редьюс работал крайне медленно, наверно от неправильных скиллов, в итоге был прикручен эластик

в приницпе на объеме бд можно не экономить в 2018, тем более для маленького проекта

И по факту монга не создавала никакого преимущества, а головняка добавляла

Хороший опыт, мне понравился, буду повторять - нет

Если бы я делал википедию, я бы юзал монгу

Версионирование, дифы из коробки

Возможность создавать неструктурированные документы - вещь.

Если бы я делал лендинги конструктор, на подобии тильды или викса - монга супер вещь. Один док на сайт, с абсолютно рандомной структурой, множеством кастомизированных только для этой страницы блоков.

@kolaz ты если будешь делать, то расскажи как тебе

ок

как думаете, mongodb для инет магазина хороший вариант?

Смотря для чего. Если только морга, то такое

Мне кажется норм до того, как придется делать кучу аналитики

Для этого своя база нужна

Да и можно взять сегмент и забить на все

а если делать своими руками, то аналитику надо делать в отдельной базе

ERROR: S client not available

и там уже можно что угодно брать

Монга предназначена для неструктурированных данных

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

как думаете, mongodb для инет магазина хороший вариант?

В плане скорости судя по бенчмаркам пг во всем хоть чуть-чуть но быстрее

В плане скорости судя по бенчмаркам пг во всем хоть чуть-чуть но быстрее

Мускл тоже неплох

Ребята у кого нить есть нормальный гем или пример дял работы с эквайрингом Газпромбанка?

Там несложно же

Откуда они лезут то? И что им надо?

Мускл тоже неплох

муслкул нинужин, постгря — наше всё :)

это еще почему

муслкул нинужин, постгря — наше всё :)

ну это смотря для каких задач

для всех, где реляционки нужны :)

для всех, где реляционки нужны :)

ну мускул для таких же задач

это еще почему

как в мускуле добавить быстро поле в табличку, в которой пара десятков миллионов записей?

как в мускуле добавить быстро поле в табличку, в которой пара десятков миллионов записей?

Точно так же как и в postres

Точно так же как и в postres

ну дык как?

как в мускуле добавить быстро поле в табличку, в которой пара десятков миллионов записей?

На одном желез мускл быстрее

Причем для мускула есть клёвые движки типа Токио

ну дык как?

* Берёшь * Добавляешь * И профит лока таблиц на простых DDL операциях уже давно нет

* Берёшь * Добавляешь * И профит лока таблиц на простых DDL операциях уже давно нет

5.7 мускул, добавить интовое поле (без дефолтного значения) жевало где то около двух часов.

в постгре такая ебала только если вкорячивашь поле с дефолтным значением

5.7 мускул, добавить интовое поле (без дефолтного значения) жевало где то около двух часов.

Добавлял varchar с дефолтном поле на таблицу в несколько гигабайт, даже на мускуле 5,5 с локами - две минуты

innodb?

Добавлял varchar с дефолтном поле на таблицу в несколько гигабайт, даже на мускуле 5,5 с локами - две минуты

39 гиг ;)

Да. Других особо вариантов и нет, кроме экзотики