Неа. Если так — это очень просто, да, и думать не надо. Нужно чтоб выполнялись условия. То есть если данная фота фходит в галерею или категорию которые НЕ опубликованы, то результат должен быть нулевым.
Да. Счас народ распросил, оказывается сайты уже неоднократно пытались ломать таким способом за последние месяца два… Хотя я уже не уверен, может это авторы стать и были?
В реальности было намного больше условий, выборок и так далее. Приходилось еще считать количество коментраиев, определять рейтинг, тэги, имена пользователей создавших галерею или фоту… Вощем, было нехило, но дело не в этом. Тут главное — способ решения. Решать по разному можно, подзапросами, джойнами и так далее…
1 запрос — это значит что решается спокойно 1-м запросом. Просто надо додуматься «как». Впрочем, в этом случае думать-то особо не надо.
Макс, ну конечно агрегатные агрегатные функции не могут использовать индекс — как иначе-то? Но тут даже и подзапросы не помогут. Ты же сам выше приводил пример эксплейна, где ясно видно что условие с хэвингом обрабатывает меньшее количество строк. Так что твой вариант с подзаросом врят-ли будет быстрее чем с JOIN… ON и HAVING. Я честно говоря в этом уверен. Как и уверен в том, что индексы у тебя не используются (ну разве что при условии id_depart = departments.id — но в случае с джойном будет тоже самое)
Но ты совершенно прав — это решается рефакторингом БД — только не так как написал. Иначе. А именно — если это самое значение COUNT хранить в отдельной таблице, а дальше при апдейте вешать триггер который будет изменять это значение в зависимости от запроса. Ну или запрос на изменение вручную делать — тут кто как хочет. Тогда при условии что на данное хранимое значение будет навешан индекс, сее будет работать. Опять же — в зависисмости от условий, а имеено выполнение запроса на получени с COUNT — операция очень частая, а обновление таблицы — редкая. Если наоборот — то заморачиваться бессмысленно.
Тут уже правильно написали, что WHERE используется ДО группировки, а HAVING после. Я вообще не понимаю — что значит лучше или хуже — это разные вещи. WHERE определяет условие выборки по которым уже дальше будет идти группировка. То есть это условие по которой будет идти сама группировка, это было бы более очевидно если бы нужно было посчитать не просто количество человек в отделе, а человек например с возрастом более 30-ти лет. После того, как выполняется выборка с условием WHERE идет группировка результата. И вот когда она уже сформирована — только тогда уже работает HAVING и только для этого он и нужен. Подзапросы никакого отношения к HAVING-у не имеют, хотя бы потому что это подзапрос, а HAVING — это фильтрция результатов текущего запроса. Да, сэмулировать можно подзапросами — только зачем?
На самом деле я ожидал что кто-нибудь в каментах обязательно задаст подобный вопрос. :-) Я не знал о сейте до сегодняшнего дня, просто мне эмблема кбюби реально напомнила эмблему отмеченного товара, поскольку в свое время рекламой его натурально забадали на всех телеканалах. И я просто в поисковике нашел ссылку — вот и все. Ответ устоит?
1 запрос — это значит что решается спокойно 1-м запросом. Просто надо додуматься «как». Впрочем, в этом случае думать-то особо не надо.
Но ты совершенно прав — это решается рефакторингом БД — только не так как написал. Иначе. А именно — если это самое значение COUNT хранить в отдельной таблице, а дальше при апдейте вешать триггер который будет изменять это значение в зависимости от запроса. Ну или запрос на изменение вручную делать — тут кто как хочет. Тогда при условии что на данное хранимое значение будет навешан индекс, сее будет работать. Опять же — в зависисмости от условий, а имеено выполнение запроса на получени с COUNT — операция очень частая, а обновление таблицы — редкая. Если наоборот — то заморачиваться бессмысленно.
Тут уже правильно написали, что WHERE используется ДО группировки, а HAVING после. Я вообще не понимаю — что значит лучше или хуже — это разные вещи. WHERE определяет условие выборки по которым уже дальше будет идти группировка. То есть это условие по которой будет идти сама группировка, это было бы более очевидно если бы нужно было посчитать не просто количество человек в отделе, а человек например с возрастом более 30-ти лет. После того, как выполняется выборка с условием WHERE идет группировка результата. И вот когда она уже сформирована — только тогда уже работает HAVING и только для этого он и нужен. Подзапросы никакого отношения к HAVING-у не имеют, хотя бы потому что это подзапрос, а HAVING — это фильтрция результатов текущего запроса. Да, сэмулировать можно подзапросами — только зачем?