Пипец))) Ты меня в доку тычешь, когда я на этой особенности тест построил.

Еще раз, для тебя. В старых версиях режим sql_mode по умолчанию установлен так, что GROUP BY можно использовать криво. В новых версиях он по умолчанию установлен в only_full_group_by, так, что не дает выполнять такие запросы. Хоть расшибись.

Я в требованиях указал версию, и что нельзя изменять базу данных. Соответственно нужно использовать дефолтный режим. Это ежику понятно, так как он не для себя пишет, и я не должен настраивать СУБД под его прихоти. Если бы он выполнил требование про версию, такого пердиманокля бы не вышло. На то и рассчитан тест.

Что касается моего запроса, он вполне корректен. Если ты говоришь обратное, то с тобой нельзя ходить в разведку. В джуны правда тебя записать можно было бы.

Поясни мне бестолочу, что у меня не так в запросе. И почему (о чудо!) он работает в дефолтной 5.7?

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Но если это будет не джун, а сильный джун, даже немного мидл? Сергей Немчинский однажды сказал, что предпочитал выбирать вакансии с меньшими требованиями чем по факту мог претендовать. Ради комфорта, особенно не первое время, пока вливаешься в коллектив и т.д.

Лучше не надо выставлять требования, за которыми кроется совершенно иной смысл. Мало ли кто как воспринимает, мы ведь не джуны, и должны рассуждать технически корректно. Вот он запомнит своё задание, потом раздуплит что такое на самом деле ООП - будет неловкая ситуация, скажет: "чего ж вы от меня хотели в тот раз на собеседовании?". Или подумает не слишком лестно. И будет прав.

Ну правда, это перебор. Сам факт попытки решить одним запросом для джуна уже норм.

Пффффф, с такими джунами у себя в фирме, ты долго в своём кресле не просидишь. Да я не знаю кто бы усидел. =)

Тут три фактора. Первый - зарплата. Если Немчинский согласится на зарплату джуна, я буду только рад . Второй, этот тест написан не для того, чтобы набрать сеньёров на вакансию джуна, а для того, чтобы узнать качества соискателя. Если он пытается решить задачу по максимуму, но при этом забивает на вводные условия, то он либо имеет проблемы с дисциплиной, либо с внимательностью. А мне не нужен человек, у которого ложные амбиции. Набрать тех, у кого в голове "смотри как я умею!", но при этом не обращает внимания на важные условия, это значит огрести проблем. И третий, нам не особо есть когда рассказывать ему, что такое класс и объект. А работать придется сходу с ними, ибо Yii. Так что самые базовые знания быть должны.

И с другой стороны, если он начнет совать туда всякие паттерны, или не дай Бог действительно напишет на ООП, то тоже будет видно, что он вовсе не джун. И такого учить специфике предприятия нет смысла, он долго не просидит на этой вакансии. Либо через три дня потребует новую должность и соответствующую ЗП, либо свалит через пару недель, потому что не его уровень, и он пришел на перебиться.

Да посмеемся вместе, только и всего. Потому что да, раздуплит обязательно, я постараюсь. И когда раздуплит, только спасибо скажет. А если вдруг обидится, пусть наберет в рот говна и плюнет в меня. Я точно не обижусь))

Еще раз, он не по этому не прошел. Я не ставил задачу решить одним запросом. Лучше бы он решил тремя. Но он решил выпендриться и попался в капкан.

Ну сижу же как то)) Дело в том, что любой джун, если он достойный джун, довольно скоро перестает им быть. И что теперь, заведомо набирать бестолочей, чтобы за кресло удержаться? Есть и другие способы.

С S.Chushkin я конечно пошутил, но вот он сходу, не разобравшись, прогнал на мой запрос. А лучше бы этого не делал, ибо выглядит теперь бледно.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Шутка в другом: если таких нынче считать джунами, то кто должен быть на позициях мидлов и сениоров?

Он решил произвести впечатление, и правильно сделал, я бы его позвал на очное.

Там не нужны никакие паттерны, достаточно примитивного transaction script-а. В том и дело, что прямое требование ООП как раз подразумевает обратное. А в итоге получается "не дай Бог действительно напишет на ООП", ну странно до невозможности. Гипотетически соискатель покажет своё задание, знакомому мидлу (или не дай Бог сениору) спросит совета как лучше решить и мнение о фирме. Какой вердикт тот вынесет, особенно не зная кто конкретно составитель теста, но вроде как тамошний тимлид?

Не понял, вам в фирму нужен толковый джуниор который "довольно скоро перестает им быть"? Ну так и что же, он не потребует зарплату превратившись в мидла?

Такое. Подбор кадров к себе в команду дело сугубо личное. Ты спросил как нам тест - мы ответили. =)

Ты не понял. Мне не нужны мидлы, ФЗП не позволяет. Пока не позволяет, проект еще развивается. Мне нужны джуны, но такие, которых не пугает аббревиатура ООП. А что такое настоящее ООП знают очень немногие. Даже мидлы. Так что если тест будет написан действительно на ООП, то такого специалиста мы просто не сможем прокормить на данном этапе. Это же касается и запроса. Лично я противник больших запросов, и для себя решал бы задачу двумя атомарными. А в DDD так вообще составные запросы не используются. Так что если задача решается одним запросом, тем более кривым, это не то впечатление, которое я ожидаю. Он еще процедуру пусть напишет, я вообще "впечатлюсь".

Ты знаешь, последнее о чем я думаю, это о том, какой вердикт мне вынесет его знакомый мидл. Тест вовсе не для этого.

Потребует, и будет прав. Но он потребует не скоро, до мидла нужно дорасти. А мидл на ставке джуна потребует её уже через несколько дней)))

Спасибо. На самом деле очень полезно ответили. Мне это пригодится на будущее.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Так он по делу все сказал, проблема не в версии мускл, а в понимании того как работает групп бай. И вот оно там юзается не корректно. То что в результате совпало ожидаемое с полученным - это стечение обстоятельств, а не гарантия.
То что запрос можно выполнить успешно - не значит, что он вернет верные данные.
И проблема вовсе не в версии, а в том что первый запрос просто не верный вне зависимости от версии и настроек мускл, на к-е вы так акцентируете внимание. Что само по себе уже не верно. Хрен его знает про второй запрос, если честно, там неопределенность убирает max() вроде.

И вот то, что ожидаемо с полученным сошлось - это то, что можно простить джуниору, сделавшему запрос. И нельзя простить синьору. Разница не в знании что бывает HAVING - это в любой книжке по cкл есть, если ее прочитать целиком, а читать книжки целиком, первое, и пожалуй, основное что бы я хотел от своего джуна. А вот понимание нюансов и того как что работает внутри это как раз то что джуна от не джуна и отличает, если говорить про техническую часть.

Человек использовавший хевинг в первом запросе- прочитал книжку по скл целиком, и решил задачу ровно как и должен был джун. Я бы брал.

И раз уж речь про версии мускл и джунов - вы реально думаете, что человек к-й ищется на джуна, т.е с большой долей вероятности не имеет никаокго опыта, знает что-то про различия в версиях мускл? Я от 10 с херном лет работаю, и не знал до этого треда, что можно не все поля селектить, когда групп бай(и честно говоря, не понимаю зачем).

И раз уж пошла речь и что бы не быть голословным, я бы сходу делал как-то так, если это можно считать 1м запросом конечно(простите за форматирование и буквы, накидывалось на коленке).

SELECT * FROM authors as a
 JOIN  ( 
        SELECT c.id_author as a_id, COUNT(c.id_author) as count, max(c.rating) as s 
        FROM poems as c
        GROUP BY c.id_author 
        HAVING COUNT(c.id_author) > 1
        ) as b on a.id = b.a_id             
 WHERE
 a.status = 1       
ORDER BY b.s DESC

Печально, когда решение о найме на работу принимает человек, придумавший задание, но сам не понимающий в чем его главная загвостка :D

_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."

Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. © AllesKlar

Даёт. Легко.

Я был неправ. Этот запрос правильный/рабочий с твоими таблицами в версии 5.7.
И всё же, этот запрос не уровня юнира. Однозначно.

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

Во-во, а нам потом исправляй.
Сейчас работаю с кодом где это используется "как правило". И вместо одного нормального запроса используется 15 атомарных. Руки бы поотрывал.

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

Думаю ты прав, - главная его загвоздка в том, что он ищет мидла на должность юниора. Возможно найдёт, всяко бывает.


_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

Да именно, подобные задачи решались и могут решаться подобными запросами. Они рабочие на всех версиях.

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

Мне плевать на групп бай на самом деле. Мне нужно видеть, обязательный человек или нет. Это первое. Я не ставил задачи решить одним запросом. Мне гораздо интереснее было бы посмотреть, как они решили бы задачу несколькими и собрали на php. Это второе. А то , что там подвох с версией, это сделано сознательно, чтобы посмотреть на дисциплину и обязательность.

А бледно он выглядит потому что сказал, что мой запрос некорректен. Вполне корректен, если вы не знаете почему, могу рассказать.

Еще раз, мне не нужно чтобы он разбирался. Он прост должен был выполнить требования. Только и всего, этого было бы достаточно. Кто отнесся к требованию с уважением, тот не пал в просак.

Какая загвоздка, я не пойму. О чем ты? О завышенных требоваиях? Такнаоборот. Я усложнял задание для того, чтобы отбить охотку делать одним запросом. Кто сделает одним, стоит подумать, а зачем ему такая маленькая вакансия?

Или о GROUP BY в моем запросе? Аргументируй тогда.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Как раз я сейчас исправляю то, что понабарагозили предшественники. Которые кстати слились. Таблицы по 180 полей, запросы черт ногу сломит. Пока база была маленькая и посещаемость невысокая, худо бедно справлялись. Как все распухло, страницы стали генериться по 12 секунд. Так что исправляй, исправляй. Как петух в жопу клюнет, вспомнишь нашу беседу.


_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Мой запрос тоже рабочий на всех версиях.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Где вы берете такие базы ну. Кто их делает ну.
Дайте хоть раз поработать с таким

_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."

Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. © AllesKlar