Я выше, совершенно не в кассу, написал запрос — это как раз ваш случай. Параметром LIMIT опередяется какое количество вам нужно. Если вы опечатались в описании задачи (судя по запросу) и хотели получить отдел(один!) где больше всего сотрудников, то вам LIMIT 1.
Если несколько — то неясен критерий («самые большие» n-отделов или с числом сотрудников > n).
>> HAVING применяется к уже вычисленным групповым операциям.
пожалуйста, будьте точнее в словах, не вводите людей в заблуждение (невольно или по незнанию — не знаю). Итак многие не знают этого оператора.
HAVING не применяется к групповым операциям, он вообще к ним никакого отношения не имеет. HAVING применяется к результату запроса, т.е. это как бы WHERE, только уже накладываемый на результат. Есть в запросе GROUP BY/DISTINCT или нет — неважно, так вот тоже можно
SELECT * FROM table
HAVING id = 5
(Любой желающий посмотрев explain такого запроса увидит, что будет обработана вся таблица, а потом клиенту отдана одна строка, тогда как с WHERE будет заюзан индекс)
Проблема HAVING в том, что его условие (cnt>5) не использует и не может использовать индексы. По сути это «вынуть всё, отдать чуть-чуть». Поэтому их необходимо по возвожности всячески избегать. Не буду утверждать за все случаи, но те, что попадались мне — решались рефакторингом БД. В данном случае поможет обычная нормализация+подзапрос (первое что пришло в голову) — разносим отелы и сотрудников в разные таблицы и пишем слудующее
SELECT
,department
,(SELECT COUNT(*) FROM employees WHERE id_depart = department.id) AS cnt
FROM departments
WHERE cnt>5
Имеем две маленькие таблички и шустрый запрос использующий индекс, вместо большой (относительно) таблицы и медленного запроса с having и без индексов. Может как то и с JOIN можно извернуться, но щас уже голова не очень работает
После пары инцидентов (у нас в основном леди работают), когда в знак благодарности нам приносили торты, стали отвечать «Админы торты не пьют!»
А по жизни поступаем просто — если люди приносят проблемный девайс на работу — делаем просто так или за что-то символическое («тортик» тот же). Если надо ехать на дом — за деньги.
в момент голоса — да, но на самом деле это косяк хабра — ничего никуда не прибавляется. если вы перезагрузите страницу, все это 0.5 исчезнут. Можете проверить сами. Сами посудите, если бы прибавлялось — было бы много (~50%) топиков, у которых оценки дробные :)
Не только. На самом деле это еще и яркий пример убогости механизма работы Хабра с RSS рекламодателей. Ну мало того, что можно было бы сделать элементарную проверку на длину текста, и ставить автоматом хабракат. Так и сами новости надо импортировать по умному, а не тупо по крону вставлять всё, что появилось в RSS. Например можно анализировать количество новостей и если их более 2-х, то репостить их на Хабре с интервалом в несколько часов. Много чего можно придумать. А так, имеем то, что имеем.
Попробую предположить, что это так кривая защита от вставки скриптов работает. Вместо того, чтобы отследить все варианты написания script, сначала слово превентивно приводится к нижнему регистру, даже не глядя на то, что слева-справа буквы (а не скобки и не %), а потом уже обрабатывается дальше.
Если несколько — то неясен критерий («самые большие» n-отделов или с числом сотрудников > n).
пожалуйста, будьте точнее в словах, не вводите людей в заблуждение (невольно или по незнанию — не знаю). Итак многие не знают этого оператора.
HAVING не применяется к групповым операциям, он вообще к ним никакого отношения не имеет. HAVING применяется к результату запроса, т.е. это как бы WHERE, только уже накладываемый на результат. Есть в запросе GROUP BY/DISTINCT или нет — неважно, так вот тоже можно
SELECT * FROM tableHAVING id = 5
(Любой желающий посмотрев explain такого запроса увидит, что будет обработана вся таблица, а потом клиенту отдана одна строка, тогда как с WHERE будет заюзан индекс)
SELECT,department
,(SELECT COUNT(*) FROM employees WHERE id_depart = department.id) AS cnt
FROM departments
WHERE cnt>5
Имеем две маленькие таблички и шустрый запрос использующий индекс, вместо большой (относительно) таблицы и медленного запроса с having и без индексов. Может как то и с JOIN можно извернуться, но щас уже голова не очень работает
EXPLAIN SELECT otdel, COUNT(sotrudnik) as cntFROM table
GROUP BY otdel
HAVING cnt>5
Explain вашего запроса:
имхо, тут бы начать с нормализации данных, разнести сотрудников и отделы по разным таблицам
SELECT otdel, COUNT(sotrudnik) AS cntFROM table
GROUP BY otdel
ORDER BY cnt DESC
LIMIT 5
регулярка на email — это просто кладезь вариантов, crjkmrjвплоть то RFC-based
В России тоже, в частности в ИНН и ОГРН
А телефония просто очень старая — тогда об этом никто не задумывался.
А по жизни поступаем просто — если люди приносят проблемный девайс на работу — делаем просто так или за что-то символическое («тортик» тот же). Если надо ехать на дом — за деньги.
Это пять! :)
Про JAVAscript — смешно, да. У такого поведения есть причины?