Phys_Math_Man, такое к сожалению возможно, если ты пилишь пет-проект. В проме у тебя, как разработчика столько работы, что доку ты физически не осилишь. Кроме того, все осложняется тем, что одну фичу пилит команда разработчиков и всех мотивировать на поддержание актуальности доки очень сложно. Также часто случается испраление ошибок и рефактортнг. И после каждого изменения в коде нужно чекать доку. А еще и ПМ со сроками напирает. Поэтому актуальная дока это очень сложно и дорого, а потому ее редко где есть.
Rsa97, однобатовые скорее всего не выйдет использовать если это магазин и там товары на кирилице, то будет юникод.
Но по факту врядли там будут сотни тысяч товаров, это уже уровень мвидео или озона. Так что скорее всего того, что есть сейчас автору вопроса хватит, а с ростом бизнеса просто перейдут на специализированный софт.
Rsa97, У меня была похожая задача, но мне не требовался like, а хватало полного совпаления пути. И чтобы индекс работал я создал отдельное поле, где зранил sha256 хэш от пути и это поле уже нормально индексиркется. Правда для поиска нужно вычислять хэш от пути. И при вставке новых категорий нужно проверять коллизии, хотя вероятность коллизий не большая.
Тут есть нюанс, на очень длинных строках индексы плохо работают. И этот вариант можется скатиться к table scan.
В задасе заявлены категории и товары, т.е. вероятность длинных путей очень большая.
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, следующий шаг - попробуйте не добавлять элементы в новые списки а сразу суммировать минимальные в одну переменную, а максимальные во вторую, а далее после цикла суммирования сравнивать значения этих двух переменных.