Ð
это разные запросы с разным планом
Size: a a a
2020 February 01
Ð
их надо хранить отдельно в виде набора разных стейтментов сессии с бд, только тогда оно будет работать эффективно (планироваться и парситься один раз, а потом вызываться как функция)
Ð
и для каждого еще и свой индекс нужен скорее всего
AK
Допустим есть таблица с n полями по которым пользователь может сортить. Это 2^n кверей хранить надо?
Ð
естественно, а как иначе? предлагаешь базе каждый раз компилировать запрос? а потом жалуются что сайты тормозят :)
AK
Ну давай будем реалистичны - для n = 10 уже никто не будет прописывать 1024 квери
ВК
Это про сырой sql насколько я понимаю? У меня сколько раз я его не использовал возникали проблемы например такого толка - нужно отсортировать данные по нескольким колонкам, причём колонки задаёт пользователь. Ну и там начинается всякая беготня с интерполяцией строки и sql инъекциями. Это как-то решается человеческими методами?
там же есть из коробки обработка юзер инпута, чтото вроде .query("SELECT $1 FROM Users", ["name, address"])
Ð
тут просто фишка в том чтобы научиться мыслить как субд, и давать ей то, что она любит. Она ответит взаимностью. Если у тебя колонок слишком много, скорее всего имена колонок являются данными, что противоречит нормальной форме, и нужна декомпозиция
AK
там же есть из коробки обработка юзер инпута, чтото вроде .query("SELECT $1 FROM Users", ["name, address"])
Для селекта наверное, а для order и where?
Ð
Для селекта наверное, а для order и where?
названия колонок это не данные, и не параметры, это часть кода запроса
Ð
от них зависит то как запрос будет работать
ВК
Для селекта наверное, а для order и where?
ну так пишешь запрос весь, расставляешь переменные, передаешь массив с инпутом, он массив санитизирует и расставляет как надо. или я не понял тебя совсем.
Ð
ну так пишешь запрос весь, расставляешь переменные, передаешь массив с инпутом, он массив санитизирует и расставляет как надо. или я не понял тебя совсем.
он имеет в виду чтобы передавать как параметр поле по которому order by или join
Ð
это антипаттерн
Ð
в теории реляционных бд это все описано еще полвека назад
AK
Давай реалистичный пример разберём - пусть есть таблица тачек и параметры - объём двигателя, цвет, цена. Пользователь передаёт массив Filter[] где фильтр это key-value где key это название поля а value это значение поля. Как этот кейс на сыром sql решить?
Ð
Давай реалистичный пример разберём - пусть есть таблица тачек и параметры - объём двигателя, цвет, цена. Пользователь передаёт массив Filter[] где фильтр это key-value где key это название поля а value это значение поля. Как этот кейс на сыром sql решить?
очень просто, в нормальной форме у тебя должна быть таблица(цы) свойств тачки, а не отдельный столбец на каждое свойство
Ð
ты просто берешь эти свойства и делаешь пачку инсертов на каждое из них
AK
> таблица свойств
Что-то вроде props: name, value, car_id?
Что-то вроде props: name, value, car_id?
Ð