Здравствуйте, Sinclair, Вы писали: S>Если вопрос в том, как строить такие запросы "мышкой" — то это не в Базы Данных, а в UI спрашивать надо.
Нет, вопрос изначально в том, что делать когда таких критериев десятки. Не приведет ли это к существенно длительному времени выполнения запроса, а соответственно, не требуется ли решать такую задачу как-то иначе, чем записывание всех критериев в один sql запрос.
Здравствуйте, CyberRussia, Вы писали:
CR>Нет, вопрос изначально в том, что делать когда таких критериев десятки. Не приведет ли это к существенно длительному времени выполнения запроса
Почти наверняка приведет.
CR>, а соответственно, не требуется ли решать такую задачу как-то иначе, чем записывание всех критериев в один sql запрос.
Скорее всего, потребуется. А как именно — я не знаю, я не до конца понимаю твой сценарий. Вот так навскидку, голый SQL тебе не очень-то и подходит.
Здравствуйте, CyberRussia, Вы писали:
CR>Здравствуйте, Sinclair, Вы писали: S>>Если вопрос в том, как строить такие запросы "мышкой" — то это не в Базы Данных, а в UI спрашивать надо. CR>Нет, вопрос изначально в том, что делать когда таких критериев десятки. Не приведет ли это к существенно длительному времени выполнения запроса, а соответственно, не требуется ли решать такую задачу как-то иначе, чем записывание всех критериев в один sql запрос.
Количество критериев мало влияет на длительность. Там есть два фактора:
1. Объём сканируемых данных, необходимых для выполнения запроса.
2. Качество плана исполнения — то есть разница между "необходимым" объёмом работы, и фактически потраченным.
Количество параметров может повлиять на второе. А первое определяется задачей, и наличием индексов.
Скорее всего, у вас будет вовсе не произвольная схема; реальным пользователям не нужна тьюринг-полнота. Значит, можно доработать ваши пять исходных таблиц несколькими view для агрегатов, и дать оператору выбирать из них.
По мере набора статистики запросов, можно докидывать индексы в таблицы, а популярные view сделать материализованными.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CyberRussia, Вы писали: CR>Нет, вопрос изначально в том, что делать когда таких критериев десятки. Не приведет ли это к существенно длительному времени выполнения запроса, а соответственно, не требуется ли решать такую задачу как-то иначе, чем записывание всех критериев в один sql запрос.
Я вообще нифига не понимаю, что вы обсуждаете...
Если быть точным — количество критериев на время выполнения запроса не влияет. Влияет их качество. Чем меньшее количество записей отфильтровывает критерий, тем быстрее запрос. То есть в любом случае запрос с критериями будет не медленнее, чем запрос без них. Агрегатные функции (aka среднее значение) отдельно, это не критерий, критерий тут "не превышает N процентов".
Напихаешь много агрегатов — будет тормозить, запихаешь туда еще двести "простых" (как ты их называешь) критериев — не будет.
Нет, задача не решается как-то иначе — любые другие решения хуже. Дешевле один раз пройтись по таблице и посчитать все агрегаты, чем делать это несколько раз.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Ромашка, Вы писали:
Р>Если быть точным — количество критериев на время выполнения запроса не влияет.
Насколько я понимаю, его "критерии" могут вызывать доп. джойны и доп. условия джойнов, что определенно повлияет на время запроса.
И чем больше будет таких "критериев", тем сложнее может оказаться жизнь оптимизатора и тем меньше шансов на то, что он справится со своей задачей оптимальным образом.
Подводных камней там хватает, сам сталкивался с похожей задачей в своё время.
Р>Агрегатные функции (aka среднее значение) отдельно, это не критерий, критерий тут "не превышает N процентов".
А с точки зрения функционала это как-то облегчает/меняет задачу?
Агрегаты считать всё равно либо надо, либо не надо, в зависимости от наличия/отсутствия "критерия", если я правильно понимаю его задачу.
Здравствуйте, _ABC_, Вы писали: Р>>Если быть точным — количество критериев на время выполнения запроса не влияет. _AB>Насколько я понимаю, его "критерии" могут вызывать доп. джойны и доп. условия джойнов, что определенно повлияет на время запроса.
Еще раз, количество критериев на время запроса не влияет. Величина выборки, в том числе join — да.
Но у автора не mysql, где за сорок лет не удосужились реализовать совсем ничего кроме nested loop, поэтому join-ы это не столь существенно.
_AB>И чем больше будет таких "критериев", тем сложнее может оказаться жизнь оптимизатора и тем меньше шансов на то, что он справится со своей задачей оптимальным образом.
Наоборот. Чем больше критериев тем проще оптимизатору и тем больше шанс на выбор оптимального плана.
_AB>Подводных камней там хватает, сам сталкивался с похожей задачей в своё время.
Да везде полно подводных камней. Он для того и программист, чтобы с ними справляться.
Вопрос был в другом — нужно ли решать задачу другим путем. Ответ — все альтернативы написанию запроса с 200 "критериями" хуже.
Р>>Агрегатные функции (aka среднее значение) отдельно, это не критерий, критерий тут "не превышает N процентов". _AB>А с точки зрения функционала это как-то облегчает/меняет задачу? _AB>Агрегаты считать всё равно либо надо, либо не надо, в зависимости от наличия/отсутствия "критерия", если я правильно понимаю его задачу.
Да. Агрегаты считаются один раз. То есть это опять же аргумент в пользу "запроса с 200 'критериями'".
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, CyberRussia, Вы писали:
CR>Как все это делать?
Не надо изобретать велосипед.
Попробуй предложить заказчику использовать готовое решение для аналитики и отчетов.
Если у вас Microsoft, то это Micrsooft SQL Server Reporting Services например (на базе OLAP), который "из коробки", ну или PowerBI.
Там вся агрегация уже сделана, ничего тормозить не будет.
Но вообще BI (Business Intelligence, отчеты, графики, вот это вот все) — это отдельная такая себе область.
В общем для создания отчетов, код писать скорее всего не надо вообще.
Здравствуйте, bnk, Вы писали: bnk>Попробуй предложить заказчику использовать готовое решение для аналитики и отчетов. bnk>Если у вас Microsoft, то это Micrsooft SQL Server Reporting Services например (на базе OLAP), который "из коробки", ну или PowerBI.
Они предоставляют возможность "из коробки" сбора данных, их анализа и отображения в GUI ? Причем все так, как хочет заказчик, который сам с трудом формулирует, что он хочет, а значит ничего настроить лично не сумеет.
Здравствуйте, _ABC_, Вы писали: _AB>Насколько я понимаю, его "критерии" могут вызывать доп. джойны и доп. условия джойнов, что определенно повлияет на время запроса. _AB>И чем больше будет таких "критериев", тем сложнее может оказаться жизнь оптимизатора и тем меньше шансов на то, что он справится со своей задачей оптимальным образом.
Именно так.
Здравствуйте, CyberRussia, Вы писали:
CR>Здравствуйте, bnk, Вы писали: bnk>>Попробуй предложить заказчику использовать готовое решение для аналитики и отчетов. bnk>>Если у вас Microsoft, то это Micrsooft SQL Server Reporting Services например (на базе OLAP), который "из коробки", ну или PowerBI.
CR>Они предоставляют возможность "из коробки" сбора данных, их анализа и отображения в GUI ? Причем все так, как хочет заказчик, который сам с трудом формулирует, что он хочет, а значит ничего настроить лично не сумеет.
Ну да. Причем мышкой, ничего писать не надо.
Если заказчик не знает, чего хочет, это нормально. Большинство не знает.
Специалисты для того и существуют, чтобы сказать заказчику, чего он хочет. Даже специализация есть — BA (бизнес аналитик)
Просто предоставь заказчику готовые варианты, пусть выбирает.
Здравствуйте, bnk, Вы писали: bnk>Просто предоставь заказчику готовые варианты, пусть выбирает.
Вариант, конечно. Но ему тогда мне не за что будет платить
Здравствуйте, CyberRussia, Вы писали:
CR>Вариант, конечно. Но ему тогда мне не за что будет платить
Это лучше, чем попытка в одиночку создать что-то похожее. Может и создашь, но не быстро и с очень высокой степенью вероятности успеешь до этого испортить репутацию у заказчика.
Здравствуйте, _ABC_, Вы писали: _AB>Это лучше, чем попытка в одиночку создать что-то похожее. Может и создашь, но не быстро и с очень высокой степенью вероятности успеешь до этого испортить репутацию у заказчика.
Меня не очень пугает испортить репутацию у того, кто не может даже внятно документацию бизнес-логики написать и при попытках уточнить в диалоге говорит: "я полагаюсь на вашу компетенцию". А при предложении продемонстрировать промежуточный релиз: "Зачем, я уверен, что вы все правильно поняли и правильно делаете".
