Size: a a a

МИЛАШКИ - (не) гей-клуб

2020 September 08

A

Alexander° in МИЛАШКИ - (не) гей-клуб
Vladimir Revenko
Вот вам интересная задачка на вечер. Осторожно, много текста! 😬

Я тут все бьюсь возможностью перехода на Монгу. Кроме того, что просто задача интересная, может и мне подскажете что-нибудь заодно. Буду только рад.

Есть каталог товаров в интернет-магазине. Входные данные:

1. У каждого товара в каталоге есть две цены:
— закупочная (магазин покупает товар по этой цене у поставщика);
— продажная (магазин продает товар по этой цене клиентам).

Эти цены передают поставщики, поэтому нам они заранее известны. Продажная всегда выше закупочной (что логично), но разница между этими ценами (маржа магазина, грубо говоря) не пропорциональна. Т.е. не 20% наценка на каждый товар или вроде того. На попсовые  товары наценка может быть и 1%, а на менее попсовые может быть и 100%. Причем, я говорю про товары одной ценовой категории.

2. Клиенты магазина могут получать несколько видов скидок:

— Ценовые колонки. Логика такая: маржу делим на 12 равных частей и создаем 13 ценовых колонок. 1 колонка ставится клиентам по умолчанию и означает, что все 12 частей маржи (т.е. полная цена) учитывается в итоговой цене для клиента. 13 колонка означает, что 0 частей от маржи учитывается в итоговой  цене (короче без маржи продает магазин).

— Ценовые колонки для отдельных товаров. Здесь вроде бы все понятно. На весь каталог мы поставили клиенту 2 колонку, а на, допустим, 5 его любимых товаров, так и быть, поставим ему 4 колонку.

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

— Фиксированные цены. Некоторым клиентам продажники обещают прописать цены по ключевым позициям прямо в приложении к договору и зафиксить из, допустим, на пол года. Поэтому здесь мы просто ставим определенную цену на определенный товар для определенного клиента. В минус работать будем или в плюс — не важно. Уговор есть уговор... ☺️

Есть и другие варианты, но они в той или иной степени являются вариациями предыдущих трех.

3. Информация по ценам обновляется каждые 15 минут. Всего в магазине несколько сотен тысяч товаров. В среднем 1000 посетителей в день.

4. Собственно, задачка. Вот мы выводим клиенту категорию «вкусняшки». У него на странице 100 товаров и это первая страница. Всего страниц, допустим, 100 штук. Т.е. в категории «вкусняшки» у нас около 10 тыс. товаров. Предположим, что клиенту менеджер установил какую-то ценовую колонку на весь каталог, плюс, штук 30 ценовых колонок на отдельные товары, а также зафиксировал цену на, допустим, 5 товаров. Товары со склада, тоже есть в этой категории. Сортировку клиент выбрал по цене от меньшего к большему.

Какова логика при выборке документов из Монги с такой сортировкой?

В SQL при выборке создается доп. поле price_final, в котором с помощью CASE WHEN THEN в поле ставится либо фиксированная цена (если найдена в подзапросе), либо по формуле от колонки для товара (если найдена в подзапросе) либо по формуле от колонки, установленной для этого клиента. Именно в таком порядке. Все отлично работает и быстро.

В Монге есть возможность подобное сделать? Т.е. считать поле на лету и сортировать по нему?
Есть всякие конвертеры из sql в монго
источник

A

Alexander° in МИЛАШКИ - (не) гей-клуб
Можно с них начать, потом допилить
источник

A

Alexander° in МИЛАШКИ - (не) гей-клуб
В консоли видно монговские команды
источник

JM

Jordan Mikel in МИЛАШКИ - (не) гей-клуб
О чем он говорил
источник

JM

Jordan Mikel in МИЛАШКИ - (не) гей-клуб
Причем тут бог
источник

A

Arthur in МИЛАШКИ - (не) гей-клуб
Jordan Mikel
О чем он говорил
Я тоже ничего не понял))
источник

VR

Vladimir Revenko in МИЛАШКИ - (не) гей-клуб
Nikita Kolmogorov
так это ж простейшая агрегация :)
Буквально только что читал, но не уловил связи. Видимо, из-за отсутствия опыта. Спасибо за наводку. $addFields в агррегации, потом сортировка по новому полю.
источник

T

Thanks ♡ in МИЛАШКИ - (не) гей-клуб
Спасибо!
источник

VR

Vladimir Revenko in МИЛАШКИ - (не) гей-клуб
Alexander°
Есть всякие конвертеры из sql в монго
Интересно звучит. Сейчас посмотрю.
источник

A

Alexander° in МИЛАШКИ - (не) гей-клуб
но вообще есть там все это, switch, case итд
источник

A

Alexander° in МИЛАШКИ - (не) гей-клуб
Аж олдскулы свело
источник

A

Alexander° in МИЛАШКИ - (не) гей-клуб
– Это не слёзы, просто ветер попал в глаз... тут больше: https://skins.webamp.org/
источник

A

Alexander° in МИЛАШКИ - (не) гей-клуб
источник

A

Alexander° in МИЛАШКИ - (не) гей-клуб
источник

A

Alexander° in МИЛАШКИ - (не) гей-клуб
источник

A

Alexander° in МИЛАШКИ - (не) гей-клуб
источник

VR

Vladimir Revenko in МИЛАШКИ - (не) гей-клуб
Alexander°
Есть всякие конвертеры из sql в монго
Ругаются на джоины 😞
источник

AR

Alex Riabtsev in МИЛАШКИ - (не) гей-клуб
Alexander°
– Это не слёзы, просто ветер попал в глаз... тут больше: https://skins.webamp.org/
ооо!!! ностальгия )))
источник

P

Purple in МИЛАШКИ - (не) гей-клуб
Лучше ли не иметь мнения и принимать любое предложенное большинством или иметь собственное, но неверное?
источник

NK

Nikita Kolmogorov in МИЛАШКИ - (не) гей-клуб
неверное мнение всегда плохо
источник