SQL

Очевидно же В))

Почему в discounts на поле id нет уникального ключа? Для уникальности скидки на один товар. Либо, если логика допускает несколько скидок товару, их нужно обрабатывать последовательно

WITH discounts(id, amount) AS ( VALUES (1, 10), (1, 20) ) , discount_amounts(id, amount) AS ( SELECT id, SUM(amount) AS amount FROM discounts GROUP BY id ) UPDATE products p SET price = p.price - d.amount FROM discount_amounts d WHERE p.id = d.id; SELECT price FROM products;

Тут напрашивается уточнение в коде

В СУБД PostgreSQL этот запрос вернет 90. Официальная документация PostgreSQL строго оговаривает это поведение: если строка таблицы соединяется более чем с одной строкой из источников в блоке FROM, то для обновления будет использована только одна из строк, а остальные будут проигнорированы. Какая именно строка выберется — недетерминировано (непредсказуемо), но на практике для конструкции VALUES (1, 10), (1, 20) движок берет первую запись. Поэтому Postgres выполнит операцию 100 - 10 = 90, а скидку 20 просто отбросит.

Похоже на очередной накат на Postgres. Проблема в том, кто пытается выполнить такой UPDATE. Т.е решение задачи в принципе должно предусматривать дедубль. И по хорошему нужно использовать merge - там гораздо труднее поймать неочевидное поведение - именно так в продакшене серьезные дяди и тети поступают.

При использовании UPDATE ... FROM с несколькими совпадающими строками в FROM результат непредсказуем. PostgreSQL применит UPDATE для каждой совпадающей строки, но порядок не гарантирован. Это не ошибка, а особенность поведения. PostgreSQL не запрещает такие запросы, но предупреждает, что результат может быть непредсказуемым.

❓ Stiven Madrid (8454104068), а ты точно не бот? Нажми на кнопку! Иначе твои сообщения будут удаляться. Вы не успели пройти капчу, ваше сообщение было удалено. Перейдите по ссылке, чтобы получить его копию и пройти проверку

2 дисконта на один товар - явно логическая ошибка. Надо сразу с нескольких сторон ограничивать такие сценарии.

⛔ Binit ROY, тебя заблокировали (Lols Ban) Пользователь в списке глобальной блокировки бота (Lols ban) — что в таком случае делать, читайте здесь. 💡 Не хотите видеть уведомления о блокировках в чате? Включите Тихий режим в настройках бота.

⛔ Clayton, тебя заблокировали (Lols Ban) Пользователь в списке глобальной блокировки бота (Lols ban) — что в таком случае делать, читайте здесь. 💡 Чтобы подобные сообщения видел только заблокированный пользователь - включи опцию Тихий режим в настройках.

⛔ Мария, тебя заблокировали (Lols Ban) Пользователь в списке глобальной блокировки бота (Lols ban) — что в таком случае делать, читайте здесь. 💡 Хотите чистую ленту без сообщений о блокировках? Включите Тихий режим.

⛔ Амина, тебя заблокировали (Lols Ban) Пользователь в списке глобальной блокировки бота (Lols ban) — что в таком случае делать, читайте здесь. 💡 Чтобы подобные сообщения видел только заблокированный пользователь - включи опцию Тихий режим в настройках.

В Django количество запросов можно проверять в unit-тестах, тогда любое исправление сразу показывает проблему N+1

WITH daily_activity AS ( SELECT DISTINCT user_id, event_time::date AS event_date FROM events ), ordered_events AS ( SELECT user_id, event_date, LAG(event_date) OVER (PARTITION BY user_id ORDER BY event_date) AS prev_event_date FROM daily_activity ) SELECT user_id, event_date AS return_date FROM ordered_events WHERE prev_event_date IS NOT NULL AND (event_date - prev_event_date) > 30;

WITH a AS ( SELECT DISTINCT user_id, event_time::date AS act_date FROM events ), P AS ( SELECT user_id, act_date, LAG(act_date) OVER (PARTITION BY user_id ORDER BY act_date) AS prev_date FROM a ) SELECT user_id, act_date AS return_date FROM p WHERE prev_date IS NOT NULL AND act_date - prev_date - 1>= 30 ORDER BY user_id, return_date;

Я бы такого "опытного разработчика" на работу не взял.. если убрать order by - то все сразу и в PG и в ORA и в MS начнет считаться правильно.