o5a, тут можно в update добавить условие в where что activations > 0.
И тогда update не будет загонять в минус поле activations. А последующая проверка срабртает, как и сейчас.
CODEFER, нужно начитать отдельным запросом (через select) после update значение поля
activations из таблицы promo в переменную и затем в проверках использовать значение этой переменной.
Akina, не всегда быстрее. Если в выборку попадает 1% всех строк таблицы, то скан не быстрее. А группировка часто под капотом включает сортировку, это можно в плане запроса увидеть. Тут как оптимизатор посчитает правильным так исделает.
Akina, тут не должно быть фулл скан.
Если в секции in небольшая выборка всех возможных значений, то не нужно весь индекс сканировать. Скан будет только по той части, где сработало условие по первому полю(это потому что индекс по сути дерево и его значения отсортированы)
Aljo, первая часть запроса - первый шаг рекурсии. А вторая, то что выпоняется на последующих шагах.
Обратите внимание на поле level.
В первом запросе оно 1 AS level, а в остальных level +1. На наждом шаге рекурсии поле level увеличивается.
WSGlebKavash, в целях перфекционизма можно ещё немного порефакторить код. Например вынести из цикла часль if, которые срабатывают только один раз. А так шаг за шагом мы пришли примерно к тому о чем писал Wataru Wataru
WSGlebKavash, вам не нужно копировать списки каждый раз чтобы взять суммы. Тут суммы i - й итерации равны сумме i-1 итерации плюс два новых элемент один из одного массива (минимального) , а второй из другого (максимального).
WSGlebKavash, следующий шаг - попробуйте не добавлять элементы в новые списки а сразу суммировать минимальные в одну переменную, а максимальные во вторую, а далее после цикла суммирования сравнивать значения этих двух переменных.
Davidaa_WoW, такое часто бывает нужно. Например это нужно при связи многие ко многим. Обычно
это решается добавлением отдельной таблицы, которая хранит эти связи.
Davidaa_WoW, с точки зрения реализации вы можете делать как вам удобно. Но с точки зрения проектирования структуры БД атрибут "активный заказ" не является атрибутом сущности "пользователь".
То что вы реализовали называется денормализация, она применяется например в витринах данных для ускорения построения отчётов. Но если у вас курс по проектированию БД, то скорее всего от вас требуется спроектировать таблицы так, чтобы они соответствовали нормальным формам и именно поэтому ваш преподаватель не принял ваше решение.
Davidaa_WoW, вам привели контр пример. У пользователя может быть брольше одного активного заказа и сохранить нормально список активных заказов в одном поле не выйдет.
Если совсем нет времени переделывать, то можно было бы добавить флаг "активный заказ" в таблицу заказов и получать список таких заказов простым запросом по идентификатору пользователя и значению флага.
Anyuta300699, судя по коду должно, но есть нюанс. Все дублирующиеся буквы будут считаться одной буквой и перестановка a(1) t a(2) будет идентично a(2) t a(1) и в выходной set будет только один экземпляр ata.
Похоже у вас рекусия.
close_after_fetching вызывается сама из себя.
bot.gateway.removeCommand({'function': close_after_fetching, 'params': {'guild_id': guild_id}})
И тогда update не будет загонять в минус поле activations. А последующая проверка срабртает, как и сейчас.