o
Народ подскажите какие курсы онлайн по с#
Size: a a a
2020 September 08
o
А все какое-то не очень, может кто смотрел что приемлемое
E
E
А все какое-то не очень, может кто смотрел что приемлемое
Очнись и взгляни на реальность, не всегда всё идёт по плану
V
V
МЛ
Народ подскажите какие курсы онлайн по с#
Из любопытства — в каких целях хочешь использовать C#?
o
Из любопытства — в каких целях хочешь использовать C#?
С виндой поиграться посмотреть что как , с пониманием так сказать
o
И вообще поидеи самый топ шарп
S
И вообще поидеи самый топ шарп
ну, шарпы реверсить легко. так могут и исходники увести)
VR
Вот вам интересная задачка на вечер. Осторожно, много текста! 😬
Я тут все бьюсь возможностью перехода на Монгу. Кроме того, что просто задача интересная, может и мне подскажете что-нибудь заодно. Буду только рад.
Есть каталог товаров в интернет-магазине. Входные данные:
1. У каждого товара в каталоге есть две цены:
— закупочная (магазин покупает товар по этой цене у поставщика);
— продажная (магазин продает товар по этой цене клиентам).
Эти цены передают поставщики, поэтому нам они заранее известны. Продажная всегда выше закупочной (что логично), но разница между этими ценами (маржа магазина, грубо говоря) не пропорциональна. Т.е. не 20% наценка на каждый товар или вроде того. На попсовые товары наценка может быть и 1%, а на менее попсовые может быть и 100%. Причем, я говорю про товары одной ценовой категории.
2. Клиенты магазина могут получать несколько видов скидок:
— Ценовые колонки. Логика такая: маржу делим на 12 равных частей и создаем 13 ценовых колонок. 1 колонка ставится клиентам по умолчанию и означает, что все 12 частей маржи (т.е. полная цена) учитывается в итоговой цене для клиента. 13 колонка означает, что 0 частей от маржи учитывается в итоговой цене (короче без маржи продает магазин).
— Ценовые колонки для отдельных товаров. Здесь вроде бы все понятно. На весь каталог мы поставили клиенту 2 колонку, а на, допустим, 5 его любимых товаров, так и быть, поставим ему 4 колонку.
— Ценовые колонки для отдельных товаров сразу для всех клиентов. Т.е. лежат на складе товары, от них всегда нужно быстрее избавляться, чтобы меньше за склад платить. Вот менеджер выбирает какую там колонку на какой товар поставить и это должно сработать для всех клиентов магазина.
— Фиксированные цены. Некоторым клиентам продажники обещают прописать цены по ключевым позициям прямо в приложении к договору и зафиксить из, допустим, на пол года. Поэтому здесь мы просто ставим определенную цену на определенный товар для определенного клиента. В минус работать будем или в плюс — не важно. Уговор есть уговор... ☺️
Есть и другие варианты, но они в той или иной степени являются вариациями предыдущих трех.
3. Информация по ценам обновляется каждые 15 минут. Всего в магазине несколько сотен тысяч товаров. В среднем 1000 посетителей в день.
4. Собственно, задачка. Вот мы выводим клиенту категорию «вкусняшки». У него на странице 100 товаров и это первая страница. Всего страниц, допустим, 100 штук. Т.е. в категории «вкусняшки» у нас около 10 тыс. товаров. Предположим, что клиенту менеджер установил какую-то ценовую колонку на весь каталог, плюс, штук 30 ценовых колонок на отдельные товары, а также зафиксировал цену на, допустим, 5 товаров. Товары со склада, тоже есть в этой категории. Сортировку клиент выбрал по цене от меньшего к большему.
Какова логика при выборке документов из Монги с такой сортировкой?
В SQL при выборке создается доп. поле
В Монге есть возможность подобное сделать? Т.е. считать поле на лету и сортировать по нему?
Я тут все бьюсь возможностью перехода на Монгу. Кроме того, что просто задача интересная, может и мне подскажете что-нибудь заодно. Буду только рад.
Есть каталог товаров в интернет-магазине. Входные данные:
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 в поле ставится либо фиксированная цена (если найдена в подзапросе), либо по формуле от колонки для товара (если найдена в подзапросе) либо по формуле от колонки, установленной для этого клиента. Именно в таком порядке. Все отлично работает и быстро.В Монге есть возможность подобное сделать? Т.е. считать поле на лету и сортировать по нему?
T
D
А когда поменяли имя канала? Вы тоже кайфануди от последнего видео про бога?
NK
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 при выборке создается доп. поле
В Монге есть возможность подобное сделать? Т.е. считать поле на лету и сортировать по нему?
Я тут все бьюсь возможностью перехода на Монгу. Кроме того, что просто задача интересная, может и мне подскажете что-нибудь заодно. Буду только рад.
Есть каталог товаров в интернет-магазине. Входные данные:
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 в поле ставится либо фиксированная цена (если найдена в подзапросе), либо по формуле от колонки для товара (если найдена в подзапросе) либо по формуле от колонки, установленной для этого клиента. Именно в таком порядке. Все отлично работает и быстро.В Монге есть возможность подобное сделать? Т.е. считать поле на лету и сортировать по нему?
так это ж простейшая агрегация :)
NK
читай про aggregation
С
Привет, ребят... Если кто могет в JS, подскажите, могу я в html коде в теге <script> сурсом указать путь до файла а не ссылку? просто сам js хотелось бы держать отдельным файлом...
С
чет я не вовремя, Никита поджопники раздает))
NK
А когда поменяли имя канала? Вы тоже кайфануди от последнего видео про бога?
/ban
S
Принято!