В очередной раз рискну разместить здесь вакансию

← →
paul_k © (2006-03-16 09:36) [160]

> [159] Bless © (16.03.06 09:07)

я давал из расчета 15-20 минут на задачу. В распоряжении кандидата только голова, бумага и ручка.

← →
Курдль © (2006-03-16 09:36) [161]

> Nikolay M. © (15.03.06 18:36) [147]

Мне бы Ваши проблемы! :)
Т.е. Вы оцениваете степень мастерства претендента по его умению выжать последние крохи быстродействия из SQL сервера? :)

← →
Igorek © (2006-03-16 09:48) [162]

> Т.е. Вы оцениваете степень мастерства претендента по его
> умению выжать последние крохи быстродействия из SQL сервера?
> :)

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

← →
paul_k © (2006-03-16 09:50) [163]

> [161] Курдль © (16.03.06 09:36)

Наоборот. Не "выжать", а "не положить".
При больших объемах данных криво написанный запрос легко может уложить любой сервер. Потери от получасового простоя сервера скажем фронтофиса, или опердня могут быть очень велики. Сажать над каждым програмистом контролера - а оно надо?. Следовательно ищутся люди у которых навыки правилного написания запросов просто "вросли в пальцы". Как мне кажется, от такого программиста ни один работодатель не откажется:)

← →
Курдль © (2006-03-16 10:13) [164]

> Igorek © (16.03.06 09:48) [162]

> paul_k © (16.03.06 09:50) [163]

Спасибо.

← →
Nikolay M. © (2006-03-16 10:15) [165]

> Bless © (16.03.06 09:07) [159]
> И еще, когда опубликуешь, напиши, сколько времени на эти
> задачки дается, пожалуйста.
> Бум ждать.

Это заочная задачка, дособеседовательная. Например, один кандидат прислал вариант с кучей SELECT FROM SELECT и не учел даже половины условий из задачи, хотя я вполне допускал, что некоторые моменты могут быть поняты неоднозначно из-за незнания предметной области и был готов закрыть на это глаза. Ввиду его завышенных пожеланий к зарплате, собеседование так и не состоялось, что сэкономило время нам обоим.
Задачку придумал на коленке, вечером, за 15 минут, она очень приближена к боевым условиям. Сам я ее не решал :)

← →
Sandman25 © (2006-03-16 10:19) [166]

Nikolay M. © (16.03.06 10:15) [165]

Сам я ее не решал :)

и вообще решить не могу :)

← →
Nikolay M. © (2006-03-16 10:20) [167]

> Igorek © (16.03.06 09:48) [162]
> paul_k © (16.03.06 09:50) [163]

Угу, все правильно. Тем более, что умение написать быстрый запрос - это всего лишь вершина айсберга, но по которой можно судить о том, что кандидат знает об устройствах индексов, что такое HAVING да и вообще, стиль написания скриптов может о многом сказать.

← →
Nikolay M. © (2006-03-16 10:21) [168]

> Sandman25 © (16.03.06 10:19) [166]
> и вообще решить не могу :)

Мне ежедневно приходится писать гораздо более сложные запросы :(

← →
Sandman25 © (2006-03-16 10:23) [169]

Nikolay M. © (16.03.06 10:21) [168]

Разве это плохо? Хотя, конечно, если действительно каждый день...

← →
Курдль © (2006-03-16 10:25) [170]

> Nikolay M. © (16.03.06 10:15) [165]

Интересно, а как Вы оценили бы кандидата, пишущего такие запросы:

select A.A_ID, A.A_NAME, D.D_NAME, (select sum(B.B_SUMMA) from B where B.A_ID = A.A_ID) as B_SUMMA, (select sum(C.C_SUMMA) from C where C.A_ID = A.A_ID) as C_SUMMA, from A left outer join (D, E, F) on D.A_ID = A.A_ID and E.D_ID = D.D_ID and F.E_ID = E.E_ID?

Это важно, поскольку у старых ораклистов и мускулистов разные подходы к таким запросам.

← →
Nikolay M. © (2006-03-16 10:29) [171]

> Sandman25 © (16.03.06 10:23) [169]
> Разве это плохо? Хотя, конечно, если действительно каждый
> день...

Нет, не плохо, но бывает, что немного надоедает :)

← →
Danilka © (2006-03-16 10:33) [172]

[170] Курдль © (16.03.06 10:25)
запрос нерабочий :)

← →
Nikolay M. © (2006-03-16 10:36) [173]

> Курдль © (16.03.06 10:25) [170]
> Интересно, а как Вы оценили бы кандидата, пишущего такие
> запросы:

Никак. Это PL/SQL, а я не знаю, насколько оптимально выполнение такого запроса ораклом. Встречал мнение, что разбиение большого страшного запроса, как это любят делать в MS SQL, в оракле не годится - вроде, оракл любит самостоятельно разруливать именно многоэтажные запросы с кучей подзапросов, джойнов и тд. Возможно, я ошибаюсь.

← →
paul_k © (2006-03-16 10:57) [174]

> [170] Курдль © (16.03.06 10:25)

Без условий задачи оценить решение? мдя...
если чесно, то увидев таблицы A,B,C,D - послал бы такого кандидата не взирая на звания и регалии и все прочее.. Ибо если человет какие псевдонимы таблицам дает - то явно не сработаемся.

← →
Nikolay M. © (2006-03-16 10:58) [175]

> paul_k © (16.03.06 10:57) [174]
> если чесно, то увидев таблицы A,B,C,D

Это пример :)

← →
Danilka © (2006-03-16 11:00) [176]

[173] Nikolay M. © (16.03.06 10:36)
это не пл/скл, а незнамо что такое. :)
по-крайней мере и mssql и орокол на такой синтаксис: join (D, E, F) ругаюцца.

← →
Nikolay M. © (2006-03-16 11:05) [177]

> Danilka © (16.03.06 11:00) [176]
> по-крайней мере и mssql и орокол на такой синтаксис: join
> (D, E, F) ругаюцца.

Где-то я точно видел такой синтаксис.
О, кажется, Курдль как-то писал...

← →
Игорь Шевченко © (2006-03-16 11:15) [178]

Курдль © (16.03.06 10:25) [170]

> Интересно, а как Вы оценили бы кандидата, пишущего такие
> запросы:

Я бы плохо оценил. Не вдаваясь в суть запроса, только по слову "SUMMA"

← →
paul_k © (2006-03-16 11:20) [179]

> [175] Nikolay M. © (16.03.06 10:58)
> Это пример :)

Нет это привычка, "вросшая в пальцы" :))

← →
Курдль © (2006-03-16 11:20) [180]

> Nikolay M. © (16.03.06 10:36) [173]
> Никак. Это PL/SQL

Нет. Это чистый ANSI.

> paul_k © (16.03.06 10:57) [174]
> если чесно, то увидев таблицы A,B,C,D - послал бы такого кандидата

Как правильно сказал Nikolay M., это общепринятая форма написания примеров. Так что поостереглись бы посылать кого не попадя :)

> Danilka © (16.03.06 11:00) [176]
> по-крайней мере и mssql и орокол на такой синтаксис: join
> (D, E, F) ругаюцца.

MS SQL должен сожрать, раз его старший брат Sybase ASA съедает.
А оракл, старше 9го, съедает с доработкой типа внутри скобок (D inner join F on F.D_ID = D._D_ID и т.д.)

← →
Курдль © (2006-03-16 11:24) [181]

> Игорь Шевченко © (16.03.06 11:15) [178]
> Я бы плохо оценил. Не вдаваясь в суть запроса, только по
> слову "SUMMA"

Забавно. Во-первых, не "SUMMA", а "В_SUMMA". И что Вы имеете против, если поле действительно означает сумму? Это не противоречит ни спецификации, ни рекомендованным стилям. А вот назвать поле "SUM" было бы и вправду трагично...

← →
Nikolay M. © (2006-03-16 11:25) [182]

> Курдль © (16.03.06 11:20) [180]
> Нет. Это чистый ANSI.

Не поверю до тех пор, пока не залезу в стандарт и не увижу такую форму записи.

SELECT * FROM sysalerts LEFT OUTER JOIN (syscategories, sysjobs) ON 1=2 Server: Msg 170, Level 15, State 1, Line 4 Line 4: Incorrect syntax near ",".

← →
Курдль © (2006-03-16 11:26) [183]

> Danilka © (16.03.06 10:33) [172]
>
> [170] Курдль © (16.03.06 10:25)
> запрос нерабочий :)
>

Разве что из-за запятой перед "from"

← →
Курдль © (2006-03-16 11:30) [184]

> Nikolay M. © (16.03.06 11:25) [182]
> Не поверю до тех пор, пока не залезу в стандарт и не увижу
> такую форму записи.

Тогда посыпаю голову пеплом и забираю свои слова про "чистый ANSI" :(
Интересно, а как бы Вы реализовали мой пример на TSQL? Или на чем бы то ни было, но чтобы он корректно отработал на MS SQL?..

← →
paul_k © (2006-03-16 11:35) [185]

> это общепринятая форма написания примеров

да??? ГОСТ в студию. Или норму опубликованую. :)
Мне всеже казалось что примеры пишуть TableA,TableB, ViewC и так далее.
Опять же - у каждого свои взгляды..

> Интересно, а как бы Вы реализовали мой пример на TSQL?

Условие задачи где?. Было бы - легко реализовали бы:)

← →
Danilka © (2006-03-16 11:37) [186]

[180] Курдль © (16.03.06 11:20)
Если "раскрыть скобки", то, таки да, съест и орокол старше 9-ки и mssql.
Но даже если все открячить, выкинуть лишние соединения, или добавить их обработку в секцию select, то, цитирую: "Без условий задачи оценить решение?".

← →
Курдль © (2006-03-16 11:37) [187]

> paul_k © (16.03.06 11:35) [185]
> Условие задачи где?. Было бы - легко реализовали бы:)

Ок! :)
Если Вам не лениво будет решить, я не поленюсь составить условие :)

← →
Nikolay M. © (2006-03-16 11:39) [188]

> Курдль © (16.03.06 11:30) [184]
> Тогда посыпаю голову пеплом и забираю свои слова про "чистый
> ANSI" :(

Да уж. Просто АНСИ - это очень убогий стандарт, поэтому был очень удивлен таким заявлением.

В том примере LEFT JOIN (A, B, C) элементарно разворачивается в 3 JOIN-а:

FROM a LEFT JOIN A ON ... LEFT JOIN B ON ... LEFT JOIN C ON ...

Вот такая форма, если не ошибаюсь, уже будет соответствовать ANSI, а подзапросы суммирования в части SELECT - нет.

Условие задачи.

Существуют следующие таблицы:
A - договор
B - заявка, относящаяся к договору, как "много-к-одному"
C - платежка, относящаяся к договору, как "много-к-одному"
D - расчетный счет, относящийся к договору, как "один-к-одному"
E - распорядитель (юр. лицо), относящийся к счету, как "один-ко-многим"
F - субъект, относящийся к распорядителю, как "один-ко-многим"

Надо составить набор данных из договоров, с указанием общей суммы заявок и общей суммы платежек по каждому и (если таковые есть) наименованиями получателей(юр. лицами), указанными в р/с договора.
(Поле "наименование" имеется только у таблицы F).

Надеюсь, не ошибся в своем "реверс-инжиниринге" :)

1.
A - договор
...
D - расчетный счет, относящийся к договору, как "один-к-одному"
а нафига?

2. Необходимы все договора, в т.ч. и те, по которым небыло ниодной заявки/платежки?
3. Нафига в твоем запросе внешние соединения, если он для решения данной задачи?
ну и т.д.

или договор м.б. без р/с, распорядителя и субъекта?

> 2. Необходимы все договора, в т.ч. и те, по которым небыло
> ниодной заявки/платежки?

Да. Пусть будет так.

> 3. Нафига в твоем запросе внешние соединения, если он для
> решения данной задачи?

В договоре может быть и не указан счет. Тогда как без внешних соединений?
Читай: "...и (если таковые есть) наименованиями получателей

"

Ни разу не возражаю против развернувшегося оффтопа, но все-таки хотелось бы обратить внимание на сабж.

Прием резюме еще не окончен.

Чё притихли? Мож у меня тоже вакансия есть?! :)

Упрощаю задачу - не поленился нарисовать модель, хоть и не совсем по первоначальному моему запросу: http://www.kurdl.h15.ru/pages/pictures/diagram.gif

[193] Nikolay M. © (16.03.06 12:29)
> Ни разу не возражаю против развернувшегося оффтопа

это хорошо :)

> но все-таки хотелось бы обратить внимание на сабж.

дык, воть, ветку поднимаем, глядишь, кто и заинтересуецца. :)

[194] Курдль © (16.03.06 13:05)
как я понял, надо 4 поля: id договора, два поля с суммами по заявкам/оплатам и еще одно - наименование субъекта, так? и в чем проблема-то? простейшая задачка. если по наименованию субъекта не требуется фильтрация/сортировка, то яб вообще взял селект из таблицы договоров и три подзапроса, два считаюших суммы, третий вытаскивающий субъекта.

> яб вообще взял селект из таблицы договоров и три подзапроса,
> два считаюших суммы, третий вытаскивающий субъекта.

А почему третий - подзапрос, а не внешнее соединение?

> Danilka © (16.03.06 13:41) [197]

А где написано, что внешнее соединение тормознутее подзапроса?

И мне интересно все-таки, как будет выглядеть такой запрос на MS SQL?

> Danilka © (16.03.06 13:31) [195]
> дык, воть, ветку поднимаем, глядишь, кто и заинтересуецца. :)

Так потому и не возражаю :)

> Курдль © (16.03.06 11:51) [189]

Типа такого:
select o.*, r.OrderRequestAmount, p.OrderPaymentAmount, jp.jpName from A as o left join ( select sum(Amount) as OrderRequestAmount, orderID from B group by orderID ) as r on o.ID = r.orderID left join ( select sum(Amount) as OrderPaymentAmount, orderID from C group by orderID ) as p on o.ID = p.orderID left join ( select ac.orderID, jp.[Name] as jpName from D as ac left join E as jp on ac.ID = jp.accountID ) as jp on o.ID = jp.orderID

В очередной раз рискну разместить здесь вакансию Найти похожие ветки