G> А потом приходит на собеседование и выясняется, что он не способен за разумное время решить несложную задачку на написание sql скрипта.
Черт его знает, наверное это где-то в подсознании лежит, потому как обычно решаются (относительно)сложные задачи довольно быстро, а потом читаешь рсдн.
А на собеседовании, наверное, другое полушарие мозга работает.
Ну не идет оно, нет сосредоточенности.
Здравствуйте, avpavlov, Вы писали:
A>Мы про СКЛ говорим? Всё нижеперечисленное применяется к кандидатам, которые заявляют в своём резюме хорошее знание СКЛ.
Активно использую Sql около 5 лет, но на большинство ваших вопросов я бы не ответил. Объясняю почему:
1) В вопросах цель подменена средством. Нет такой задачи применить join к таблице, есть задача на основании двух таблиц получить третью отвечающую определенным требованиям.
2) Я не стремлюсь запомнить и соответственно не помню тонкости sql, т.к. это совершенно не нужно для решения реальных задач. При решении реальной задачи всегда есть и таблички, для которых пишется запрос, и Sql viewer, и гугль, и ранее написанный код. Поэтому если что-то помнишь смутно или в чем-то сомневаешься, то уточнение занимает от силы пару минут.
3) В вопросах имеется куча экзотики, мало применимая или и вовсе бесполезная на практике.
select * from t1, t2
Я достаточно часто использую запросы вида select accounts.client_id, clients.client_name, accounts.login from accounts, clients Where accounts.client_id = clients.client_id и соответственно если меня неожиданно спросить может даже вспомню, что этот запрос возвращает (хотя могу и не вспомнить). Но я никогда не использовал выборку из двух таблиц без условия и не представляю себе задачу где бы это могло пригодиться.
select distinct * from t1, t2
Только сейчас узнал о существовании distinct'а в sql'е. Это, конечно, минус к моему sql'ому образованию, но решение реальных задач от этого никак не страдало, т.к. distinct это по сути урезанный по возможностям вариант group by.
A> На мой взгляд джойны это из разряда указателей в языке С, некоторые никогда не смогут понять как это работает (не знаю почему). Это азы СКЛ и если человек пишет в резюме 5 лет SQL и не может на эти вопросы ответить, то просто рискованно его брать.
Пять лет назад я мог ответить на вопросы по join'ам. Сейчас на память даже синтаксис не вспомню. Т.к. я не припомню ни одной реальной задачи, в которой left join или right join был бы реально нужен. Вместо inner join для меня удобнее и понятнее использовать выборку из двух таблиц со связыванием их через условие.
Так что может и быть join'ы это действительно тоже, что у указатели в C, но на практике они нужны точно также как указатели в C#.
Здравствуйте, divergo, Вы писали:
D>и на просьбу написать запрос(на бумажке) выдал WHERE field1 = NULL, ясное дело, должно быть IS NULL D>На работе IS NULL писал автоматом не задумываясь, а здесь черт дернул
Это естетственно. То с чем постоянно работаешь уходит на уровень подсознания, но на собеседование подсознание не работает, т.к. обстановка не привычная. А сознание уже давным давно забыло как к этой информации обращаться. Поэтому требование на собеседовании точного синтаксиса это редкостный маразм.
Здравствуйте, divergo, Вы писали:
G>> А потом приходит на собеседование и выясняется, что он не способен за разумное время решить несложную задачку на написание sql скрипта. D>Черт его знает, наверное это где-то в подсознании лежит, потому как обычно решаются (относительно)сложные задачи довольно быстро, а потом читаешь рсдн. D>А на собеседовании, наверное, другое полушарие мозга работает. D>Ну не идет оно, нет сосредоточенности.
Конечно на собеседовании сложнее, ну так и задачи на собеседованиях обычно дают гораздо проще, чем встречаются в реальной жизни.
FD>>из которых правильный только последний (нормализованный).
A>Это уже обсуждалось в "базах данных" поэтому не хочу спорить ещё раз, но замечу, что слепая вера в живительную силу тотальной нормализации в моих глазах является минусом. Нормализация просто один из инструментов в арсенале программиста и, как каждый инструмент, он может быть подходящим или нет.
Немного не так: нормализация — один из основных (или основной) методов проектирования БД (имеется в виду OLTP). Денормализация — один из методов улучшения производительности.
Правильный подход в проектировании БД заключается в том, чтобы сначала создать полностью нормализованную структуру БД, потом некоторые части денормализовать, если это необходимо.
A>Хочешь продолжить спор — ступай в БД
Примитив.
А если бы Вам пришлось набирать водителей?,
Вы бы для начала попросили их проехаться на роликах, затем на велосипеде,
затем посадили в авто и спросили где педаль тормоза — а где сцепления
и какая последовательность переключения передач
до езды бы у вас не дошло — никто бы не прошел.
Здравствуйте, Flying Dutchman, Вы писали:
A>>Когда закончили с листком (у действительно опытных это занимает менее 10 минут), далее просто проверяю способность кандидата рассуждать, спрашивать, обосновывать и т.д. — прошу спроектировать несколько таблиц, связи между ними, почему так, а не этак, какие операции будет удобно делать, а какие неудобно, что нужно сделать, чтобы и эти было удобно ну и т.д.
FD>Интересно, и как это структура таблиц может зависеть от "удобства выполнения операций" ?
Классический пример — хранение деревьев в реляционной БД. Различные способы имеют различные скорости модификации, поиска, перечисления и т.д.
U>1) В вопросах цель подменена средством. Нет такой задачи применить join к таблице, есть задача на основании двух таблиц получить третью отвечающую определенным требованиям.
Если ты не знаешь джойны, то ты не сможешь решить задачу, ни мою ни свою.
U>2) При решении реальной задачи всегда есть и таблички, для которых пишется запрос, и Sql viewer, и гугль,
Я тебе наверное скажу новость, но SQL не прощает такого подхода. Если ты не понимаешь как работает запрос, то всё закончится тупым подбором каких-то магических операторов, которые на текущей тестовой базе дадут правильный ответ. И неправильный на продакшн.
U>3) В вопросах имеется куча экзотики, мало применимая или и вовсе бесполезная на практике. U>select * from t1, t2
ОФИГЕТЬ
U>Т.к. я не припомню ни одной реальной задачи, в которой left join или right join был бы реально нужен. Вместо inner join для меня удобнее и понятнее использовать выборку из двух таблиц со связыванием их через условие.
ОФИГЕТЬ
U>Так что может и быть join'ы это действительно тоже, что у указатели в C, но на практике они нужны точно также как указатели в C#.
ОФИГЕТЬ
U>Активно использую Sql около 5 лет, но на большинство ваших вопросов я бы не ответил. Объясняю почему:
Вот собственно от таких как ты мы и защищаемся при наборе, твой пост добавлю в избранное, буду постить в ответ на "зачем спецу с 5летним опытом дают решать задачки".
Здравствуйте, genre, Вы писали:
G>Не, я вот правда не понимаю. Есть у нас программист, который на работе, в течении нескольких лет достаточно регулярно пишет sql скрипты разной сложности. А потом приходит на собеседование и выясняется, что он не способен за разумное время решить несложную задачку на написание sql скрипта. G>Какие выводы можно из этого сделать? У меня всего два получаются: G>1. Он никаких скриптов на работе не писал, те врет. G>2. каждый новый несложный скрипт потребует у него "пару дней чтобы вспомнить" (см сообщение рядом).
3. Ваша тестирование не адекватно.
Я уверен, что моих знаний sql хватит для большинства задач. Но при этом я его не использовал уже года 4, если не 5. Кроме простейшего select-а написать вообще ничего не смогу.
Естественно, если потребуется устраиваться на работу, где нужен sql — быстро "нагоню" знаний, пролистав книжку.
А если последнее время человек действительно этим sql занимался, то знания у него есть.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, avpavlov, Вы писали:
Да не спорь ты с павловым — вы на разных уровнях развития находитесь, посему друг друга не понимаете.
Донести до другого человека всю совокупность твоего отношения к делу невозможно — можно только выбирать людей, полностью разделяющих твои взгляды, а не понимающих просто обходить стороной.
Здравствуйте, alzt, Вы писали:
G>>Не, я вот правда не понимаю. Есть у нас программист, который на работе, в течении нескольких лет достаточно регулярно пишет sql скрипты разной сложности. А потом приходит на собеседование и выясняется, что он не способен за разумное время решить несложную задачку на написание sql скрипта. G>>Какие выводы можно из этого сделать? У меня всего два получаются: G>>1. Он никаких скриптов на работе не писал, те врет. G>>2. каждый новый несложный скрипт потребует у него "пару дней чтобы вспомнить" (см сообщение рядом).
A>3. Ваша тестирование не адекватно. A>Я уверен, что моих знаний sql хватит для большинства задач. Но при этом я его не использовал уже года 4, если не 5. Кроме простейшего select-а написать вообще ничего не смогу. A>Естественно, если потребуется устраиваться на работу, где нужен sql — быстро "нагоню" знаний, пролистав книжку.
A>А если последнее время человек действительно этим sql занимался, то знания у него есть.
тут все зависит от того какого уровня человек нужен. если писать несложные скрипты, то можно вообще не тестировать на знание sql — научиться писать несложные скрипты способен любой вменяемый программист. а если нужен человек способный писать реально сложные запросы то "нагоню" здесь работает не всегда. сколько ты будешь нагонять до уровня гуру?
__>>>и проведение собеседования это просто часто повод поболтать с кем-то, познакомиться поближе A>>Мне только остаётся спросить — сколько собеседований ты в жизни провёл? Или ты теоретически рассуждаешь? __>да штук 10-то провел. но причем тут я? у меня свои подходы, я сужу больше чисто по психологии и по увиденному в других компаниях когда собеседовали меня. иногда было видно, что я им нафиг не нужен, им просто охота поболтать. как-то так?
On 13.07.2011 14:59, avpavlov wrote:
> U>3) В вопросах имеется куча экзотики, мало применимая или и вовсе > бесполезная на практике. > U>select * from t1, t2 > > *ОФИГЕТЬ*
Приведите какой-нибудь примерчик жизненный для такого запроса, для чего
он у вас используется. А то с остальным в целом согласен, а вот тут не
могу сообразить для чего бы такой запрос мог понадобиться. Хотя с SQL
лет уж 10 минимум опыта, не вспоминается похожего.
H>Приведите какой-нибудь примерчик жизненный для такого запроса, для чего H>он у вас используется. А то с остальным в целом согласен, а вот тут не H>могу сообразить для чего бы такой запрос мог понадобиться. Хотя с SQL H>лет уж 10 минимум опыта, не вспоминается похожего.
ну, например, есть люди. У них 2 признака — пол и национальность. Построить отчёт с группировкой по полу и национальности, включая нулевые значения.
select
breakdown.*
,count(*)
from
(
select gender.code gender, ethnic.code ethnic from gender,ethnic
) breakdown
left join people on people.gender = breakdown.gender and people.ethnic = breakdown.ethnic
group by
breakdown.gender
,breakdown.ethnic
Собственно, люди, которые "умеют объяснить" поведение с условием (select * from t1,t2 where t1.x=t2.y), но не могут объяснить поведение без условия (select * from t1,t2), практически в 100% случаев на вопрос "найти все значения т1 которые не встречаются в т2 без использования вложенных запросов" пишут "from t1,t2 where t1.x != t2.y" — потому что они тупо не понимают, что внутре у этой неонки происходит.
При этом считают, что задавать такие вопросы — западло
DD>Да не спорь ты с павловым — вы на разных уровнях развития находитесь, посему друг друга не понимаете. DD>Донести до другого человека всю совокупность твоего отношения к делу невозможно — можно только выбирать людей, полностью разделяющих твои взгляды, а не понимающих просто обходить стороной.
Если бы вы оба перестали воспринимать отказ в приёме на работу как оскорбление, то вам бы легче стало жить.
A>select
A> breakdown.*
A> ,count(*)
A>from
A> (
A> select gender.code gender, ethnic.code ethnic from gender,ethnic
A> ) breakdown
A> left join people on people.gender = breakdown.gender and people.ethnic = breakdown.ethnic
A>group by
A> breakdown.gender
A> ,breakdown.ethnic
A>
On 13.07.2011 17:39, avpavlov wrote: > From: *avpavlov* </Users/12804.aspx>
, практически в 100% случаев на вопрос > "найти все значения т1 которые не встречаются в т2 без использования > вложенных запросов" пишут "from t1,t2 where t1.x != t2.y"
Да ладно, не может быть чтоб такое писали.
Они наверное над вами глумятся просто
H>Да ладно, не может быть чтоб такое писали. H>Они наверное над вами глумятся просто
Ну я в ответ прошу расписать резалтсет, так что глумление тут взаимное выходит тогда
Многие люди в этом и других подобных топик думают "это легкотня, я это с пелёнок знаю и отвечаю ночью спросонья. Спрашивать такое — западло". А на самом деле они меряют по себе и не понимают, что есть куча других людей (с 5ним опытом, ага), для которых это ящик с неонкой.
Здравствуйте, avpavlov!
A>...есть куча других людей (с 5-ним опытом, ага), для которых это ящик с неонкой.
На концептуальность этой проблемы обратил внимание ещё великий Гаусс:
"...Я требую, чтобы всякий раз, когда используется какая-либо система обозначений,
и всякий раз, когда используется какое-либо конкретное понятие, глубоко осознавались исходные посылки,
а свойства самого механизма и результаты его применения никогда не рассматривались в отрыве
от строгой правомерности его применения."
Из писем Гаусса Шумахеру 15мая 1843 года и 1 сентября 1850 года.
.
