Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: SQL тест'ик - прислали до собеседования  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
Кот Матроскин
в этом случае тест прекрасно выполнит свою задачу - отсеет людей, которые не могут (или не хотят) заниматься такими вещами. Тесты ведь не должны показывать, кто "хороший" специалист, а кто - "плохой", они должны показывать, кто - "подходящий", а кто - нет.

Согласен. Готов заменить "абсолютно идиотское" на "показывает людей, почти стопроцентно не являющихся подходящими с моей точки зрения работодателями".

Кот Матроскин
А задачу про удаление дубликатов я бы решал так - сделал бы копию таблицы по структуре, залил бы нее данные distinct'ом,

Я не зря упомянул про работающих пользователей, которым нельзя мешать. Пока Вы будете гонять данные - они их отредактируют. В той таблице, которую Вы дропнете.

Кот Матроскин
А ограничение "в один запрос" - очевидно, к реальной жизни имеет еще меньше отношения, чем "стандартный sql"

А где Вы у меня его нашли? Честно говоря, склонность придумывать отсутствующие условия задачи (частая у собеседуемых) говорит больше, нежели любые неправильные решения.
5 апр 05, 18:00    [1442970]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 8933
softwarer

надеюсь, Вы помните про то, что пользователи работают и мешать им нельзя; соответственно, любые варианты типа select distinct туда-сюда идут лесом).

???
Пускай даже мы рассматриваем случай Oracle и удаление таблицу не блокирует - но там же данные неверные! И, следовательно, запрос,
join'ящий эту таблицу, вернет чепуху.
Я считаю, что гораздо лучше, если запрос ждет или отваливается по таймауту, чем если возвращает неверные данные. Не согласны?
5 апр 05, 18:04    [1442983]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
ChA
Member

Откуда: Москва
Сообщений: 11124
softwarer
надеюсь, Вы помните про то, что пользователи работают и мешать им нельзя; соответственно, любые варианты типа select distinct туда-сюда идут лесом
Нда, изобретаем на лету, сначала у нас админы все поотключали, понакатили, одновременно здесь же у нас пользователи, которым мешать нельзя. Типа, админы, вроде как ничего страшного и не сделали, система прекрасно продолжает работать, несмотря на дубликаты, отключенные ограничения с индексами... Верю в Вашу фантазию, но может пора огласить весь список условий, сопровождающих сию нетривиальную операцию ?

P.S. Полагаю, у Вас еще труднее пройти собеседование, чем у любителей стандартов...
5 апр 05, 18:29    [1443074]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
Кот Матроскин
Пускай даже мы рассматриваем случай Oracle и удаление таблицу не блокирует

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

Кот Матроскин

- но там же данные неверные! И, следовательно, запрос,
join'ящий эту таблицу, вернет чепуху.

При определенных условиях - да. Вопрос - что это за условия.

Кот Матроскин

Я считаю, что гораздо лучше, если запрос ждет или отваливается по таймауту, чем если возвращает неверные данные. Не согласны?

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

Простой пример - однажды случилось так, что в новой версии пакета допустили ошибку, проявлявшуюся на крупных выборках. В результате я примерно час сидел на телефоне и диктовал кладовщице, в каком порядке нажимать на кнопки - ошибка не случалась, если заказ обрабатывался по частям при соблюдении некоторых условий. Почему?

Да, можно было вернуть предыдущую версию. Для этого потребовалось бы минут на двадцать остановить даже не весь склад, а весь офис. Что, мягко говоря, куда дороже часа моего времени. Хотя "теоретически" правильным, конечно, было бы откатиться.

Почему "теоретически" в кавычках - потому что правильная теория соответствует правильной практике. Но если теорию применять на уровне "запрещается использовать goto" - тогда да, практика вносит коррективы.

В данном случае - Вы исходите из неких предположений о данных, хотя для этого нет никаких оснований. Не хочется погружаться все глубже в пример, который я дал исключительно для иллюстрации мелкого факта; поверьте, что я готов описать ситуацию, где в такой ситуации будут более или менее нормально работать ключевые бизнес-процессы, и ситуацию надо будет править online. Кстати - не обращали внимание, что в серверах идет тенденция именно к развитию онлайновых операций администрирования? Как полагаете, почему?
5 апр 05, 18:43    [1443105]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
ChA
Нда, изобретаем на лету,

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

ChA
сначала у нас админы все поотключали,

Снова врете. Не "все" а "первичный ключ".

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

Может, скажете, пользователи не входили в данную мной постановку? Хватит духу сказать, что и это я придумал на лету?

ChA
Типа, админы, вроде как ничего страшного и не сделали,

Админы сделали одно страшное - задублировали данные. Ничего страшного, кроме этого, допустим, не сделали.

ChA
система прекрасно продолжает работать, несмотря на дубликаты, отключенные ограничения с индексами...

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

ChA
Верю в Вашу фантазию, но может пора огласить весь список условий, сопровождающих сию нетривиальную операцию ?

Я как раз весь список огласил.

ChA
P.S. Полагаю, у Вас еще труднее пройти собеседование, чем у любителей стандартов...

Зависит от. В принципе, у меня не столько практики, чтобы делать обоснованные статистические обобщения. Возможно, те, кто (более или менее успешно) собеседовался у меня, выскажут свои впечатления.

Могу сказать, что с тех курсов, которые я вел в "МВ", "себе" я бы взял на работу примерно треть или четверть из присутствовавших на них. "МВ", само собой, брала почти всех.
5 апр 05, 18:57    [1443131]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 8933
Флеймовая какая-то тема получилась - я, наверно, прекращаю в ней участвовать.
Кстати, вижу в этом еще одно достоинство изначального теста, вон какое столкновение мнений вызвал, показал участников с разных сторон - что для собеседования и нужно.Никогда вопрос про какие-нибудь оракловые rowid'ы бы такого не вызвал :)
5 апр 05, 19:18    [1443179]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
Ну вот, пошли извраты...
1
select * from
(SELECT d,LAG(p, 1, 0) 
  OVER (ORDER BY d) AS P1
FROM t)
where p1 = 1


ORDER BY в подзапросах ... ФУ !!
5 апр 05, 19:28    [1443202]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
MasterZiv
ORDER BY в подзапросах ... ФУ !!

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

Правда, справедливости ради, хотелось бы выслушать, чем "ORDER BY в подзапросе" отличается от "TOP в подзапросе" :)
5 апр 05, 19:30    [1443207]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
Очень плохой тест ! Мало того, что из задания не понятно, что такое "предыдущее значение D" (например, для 5-ого числа записи нет, что ж должно тогда считаться предыдущим для 6-го), но и вообще SQL плохо предназначен для обработки данных в каком-то определенном порядке. Запрос написать конечно можно (он достаточно прост) :

select t0.*
from T t0
where t0.P = 1
  and exists (
    select *
    from T t1
    where t1.D = ( select max(t2.D) from T t2 where t2.D < t0.D )
      and t1.P = 0
  )
5 апр 05, 19:35    [1443221]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
Castor
ответ от автора теста:


А, тоже некошерно. Подзапросы во FROM. Не ANSI. Ну точнее может быть это и есть в стандарте, но не все СУБД такое поддерживают.
5 апр 05, 19:41    [1443237]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
MasterZiv
А, тоже некошерно. Подзапросы во FROM. Не ANSI. Ну точнее может быть это и есть в стандарте, но не все СУБД такое поддерживают.


C GROUP BY намного быстрее будет, чем подзапросы с (TOP 1 .. ORDER BY), имхо. Это и было критерием правильности, скорее всего, а не стандарты.
5 апр 05, 19:45    [1443245]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
Насчет требований "на стандартном SQL". Если я тестирую товарисча, а он мне пишет например на DB2-шном (или это Оракл ? но не важно) CONNECT BY, которого я не знаю, то как я смогу вообще оценить правильность выполнения задания ? Допустим, я ему даже поверю. Он прийдет работать у нас, где этого его сервера НЕТУ, а есть другой. Как он будет работать, если он тривиальный запрос (других на собеседовании быть не может) не может написать без этой его фичи ?
5 апр 05, 19:48    [1443251]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
softwarer

Правда, справедливости ради, хотелось бы выслушать, чем "ORDER BY в подзапросе" отличается от "TOP в подзапросе" :)


Ничем. Поэтому я такие варианты и не стал комментировать.
5 апр 05, 19:51    [1443257]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
www.fun4me.narod.ru

C GROUP BY намного быстрее будет, чем подзапросы с (TOP 1 .. ORDER BY), имхо.


И ты еще хочешь говорить о скорости, если не задана даже СУБД, не говоря уже о объемах таблицы и пр ?
5 апр 05, 19:53    [1443261]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
MasterZiv
www.fun4me.narod.ru

C GROUP BY намного быстрее будет, чем подзапросы с (TOP 1 .. ORDER BY), имхо.


И ты еще хочешь говорить о скорости, если не задана даже СУБД, не говоря уже о объемах таблицы и пр ?


Не хочу. На MSSQL с GROUP BY было бы быстрее на большой таблице.
5 апр 05, 19:56    [1443267]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
Судя по профилю автора это Interbase.
5 апр 05, 20:00    [1443272]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
ChA
Member

Откуда: Москва
Сообщений: 11124
softwarer
Врете. Я не сказал ничего, что не соответствует постановке. Сначала Вы изобрели "одним запросом", теперь приписываете мне свой подход.
Где это ? Здесь
ChA
softwarer
А на стандартном SQL задача вообще вряд ли решаема.
Одним запросом, пожалуй, да...
?
Констатация факта, не более, причем здесь Вы ? Или здесь
ChA
В конкретной ситуации принимаются и конкретные решения. В ней обычно не до красивостей, типа, непременно одним запросом.
?
Опять же, причем здесь Вы ? Опять же, общее рассуждение, что это Вы так завелись ?
softwarer
Снова врете. Не "все" а "первичный ключ".
Смутно напоминает анекдот, не дословно, как помню: "Почему вы не смогли удержать крепость ?" - "На это было 3 причины. Во-первых не было пороха...". Хорошо, признаю, наврал, не все, а всего лишь "первичный ключ"...
softwarer
Может, скажете, пользователи не входили в данную мной постановку? Хватит духу сказать, что и это я придумал на лету?
Запросто, действительно, не придумали, были, особенно впечатляет жизненность ситуации...
softwarer
Ничего страшного, кроме этого, допустим, не сделали.

Да уж, страшнее только удалить данные при полном отсутствии бакапов...
softwarer
Большая часть системы при этом запросто может нормально работать. Мало того, вполне реальны ключевые бизнес-процессы, затрагивающие дублируемые данные, но тем не менее, работающие (возможно, с соответствующей инструкцией пользователям).
Мне не хватает фантазии представить такую систему, но особенно ее ценность, если за нее отвечают такие админы...
5 апр 05, 20:23    [1443308]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
Владимир Бегун
Member

Откуда: Redwood Shores, CA USA
Сообщений: 1707
softwarer

ChA
сначала у нас админы все поотключали,

Снова врете. Не "все" а "первичный ключ".

+ все foreign keys, которые ссылаются на этот "первичный ключ" (ORA-02297)
+ индекс первичного ключа
SQL> CREATE TABLE softwarer(p NUMBER PRIMARY KEY);

Table created.

SQL> SELECT index_name, status FROM user_indexes WHERE table_name = 'SOFTWARER';

INDEX_NAME                     STATUS
------------------------------ --------
SYS_C00223263                  VALID

SQL>  ALTER TABLE softwarer DISABLE CONSTRAINT SYS_C00223263;

Table altered.

SQL> SELECT index_name, status FROM user_indexes WHERE table_name = 'SOFTWARER';

no rows selected
Что мы имеем в результате, как минимум (при данной формулировке задачи):

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

- поедут планы запросов...

- поскольку не сказано что таблица маленькая, она может быть большой,
поскольку не сказано каков был объём загруженных данных, а он может
быть большим, то решение с exception table -- будет не тем быстрым, которое
ищется...

Меняй пример или формулируй чётко, да и на счёт "врете"... :-) это ты
погорячился. Человек сделал правильные выводы из того что ты сказал,
поскольку твоя "высосаная из пальца" задачка ничем не лучше оригинального
вопроса о выборке.
5 апр 05, 21:22    [1443343]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
Andrew Lening
Member

Откуда: Иваново
Сообщений: 315
Castor
для тех кто хочет поупражняться с SQL'ем


Таблица Т. Два поля D и P

01.01.2004	0	
02.01.2004	0	
03.01.2004	1	
04.01.2004	1	
06.01.2004	0	
07.01.2004	1	
08.01.2004	0	
09.01.2004	1	
11.01.2004	1	
14.01.2004	0


Вывести записи значения в которых P=1 и предыдущее (по полю D) значение P=0

т.е. должны быть выведены записи за 3.01, 7.01, 9.01


Вот, сочинил довольно красивую штуку:

select t1.d
from t t1 join t t2 on (t2.d<t1.d)
where not exists (select * from t t3 
 where t3.d>t2.d and t3.d<t1.d) 
and t1.p=1 and t2.p=0
5 апр 05, 21:35    [1443355]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
www.fun4me.narod.ru
MasterZiv
А, тоже некошерно. Подзапросы во FROM. Не ANSI. Ну точнее может быть это и есть в стандарте, но не все СУБД такое поддерживают.


C GROUP BY намного быстрее будет, чем подзапросы с (TOP 1 .. ORDER BY), имхо. Это и было критерием правильности, скорее всего, а не стандарты.


IMHO, говорите... А вот планы выполнения о другом говорят!

SET LANGUAGE russian
go

DECLARE @Table TABLE(D datetime PRIMARY KEY CLUSTERED, P int)

INSERT INTO @Table VALUES('01.01.2004',	0)	
INSERT INTO @Table VALUES('02.01.2004',	0)
INSERT INTO @Table VALUES('03.01.2004',	1)
INSERT INTO @Table VALUES('04.01.2004',	1)
INSERT INTO @Table VALUES('06.01.2004',	0)
INSERT INTO @Table VALUES('07.01.2004',	1)
INSERT INTO @Table VALUES('08.01.2004',	0)
INSERT INTO @Table VALUES('09.01.2004',	1)
INSERT INTO @Table VALUES('11.01.2004',	1)
INSERT INTO @Table VALUES('14.01.2004',	0)

SELECT
  *
FROM
  @Table T1
WHERE
  (T1.P = 1) AND
  (SELECT TOP 1 P FROM @Table WHERE D < T1.D ORDER BY D DESC) = 0

SELECT TT.D,TT.P
FROM
(
SELECT T1.D,T1.P,Max(T2.D) as PrevD
FROM @Table T1
INNER JOIN @Table T2 On T1.D>T2.D
GROUP BY T1.D,T1.P
) TT INNER JOIN @Table T3 ON TT.PrevD=T3.D
WHERE TT.P=1 and T3.P=0

StmtText                                                                                                       
-------------------------------------------------------------------------------------------------------------- 
  |--Filter(WHERE:(@Table.[P]=0))
       |--Nested Loops(Inner Join, OUTER REFERENCES:([T1].[D]))
            |--Clustered Index Scan(OBJECT:(@Table AS [T1]), WHERE:([T1].[P]=1))
            |--Compute Scalar(DEFINE:(@Table.[P]=@Table.[P]))
                 |--Top(1)
                      |--Clustered Index Seek(OBJECT:(@Table), SEEK:(@Table.[D] < [T1].[D]) ORDERED BACKWARD)

(6 row(s) affected)

StmtText                                                                                                                  
------------------------------------------------------------------------------------------------------------------------- 
  |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1002]))
       |--Stream Aggregate(GROUP BY:([T1].[D]) DEFINE:([Expr1002]=MAX([T2].[D]), [T1].[P]=ANY([T1].[P])))
       |    |--Nested Loops(Inner Join, OUTER REFERENCES:([T1].[D]))
       |         |--Clustered Index Scan(OBJECT:(@Table AS [T1]),  WHERE:([T1].[P]=1) ORDERED FORWARD)
       |         |--Clustered Index Seek(OBJECT:(@Table AS [T2]), SEEK:([T2].[D] < [T1].[D]) ORDERED FORWARD)
       |--Clustered Index Seek(OBJECT:(@Table AS [T3]), SEEK:([T3].[D]=[Expr1002]),  WHERE:([T3].[P]=0) ORDERED FORWARD)

(6 row(s) affected)
6 апр 05, 10:10    [1443941]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
хррр
Guest
я ж сразу и сказал - self-join
по ANSI - кошерно ;-)
6 апр 05, 10:48    [1444200]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
Andrew Lening
Member

Откуда: Иваново
Сообщений: 315
хррр
я ж сразу и сказал - self-join
по ANSI - кошерно ;-)


Интересно, что было бы, если бы автор так на собеседовании и ответил - селф-джойн, че тут еще не понятного? :-)
6 апр 05, 13:43    [1445272]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
pkarklin> IMHO, говорите... А вот планы выполнения о другом говорят!

Согласен. Ваш запрос быстрее. Я был не прав. Вчера просто сервера под рукой не было...

Ещё вот так можно извратиться - без подзапросов:-

SELECT T1.D,T1.P
FROM #T T1
    JOIN #T T2 On T2.D<T1.D AND T2.P=0
    LEFT JOIN #T T3 On T3.D<T1.D AND T3.P <> 0
WHERE T1.P=1
GROUP BY T1.D, T1.P
HAVING (MAX(T2.D) > MAX(ISNULL(T3.D,'1900-01-01')))
6 апр 05, 15:24    [1445866]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
Владимир Бегун
+ все foreign keys, которые ссылаются на этот "первичный ключ" (ORA-02297)

Это само собой.

Владимир Бегун
+ индекс первичного ключа

А вот это совершенно не обязательно. И зная твою квалификацию, мне даже странно напоминать об этом.

SQL> 
SQL> create table tab (i integer not null);

Table created.

SQL> create index tab_pk on tab (i);

Index created.

SQL> alter table tab add constraint tab_pk primary key (i);

Table altered.

SQL> select index_name from user_indexes where table_name = 'TAB';

INDEX_NAME                                                                      
------------------------------                                                  
TAB_PK                                                                          

SQL> alter table tab drop constraint tab_pk;

Table altered.

SQL> select index_name from user_indexes where table_name = 'TAB';

INDEX_NAME                                                                      
------------------------------                                                  
TAB_PK                                                                          

Владимир Бегун

- возможность появления проблем с целостностью данных, я сильно сомневаюсь что найдётся герой,

По моему опыту, герои находились даже тогда, когда я настаивал на "закрыть". А я большинство проблем предпочитаю решать без резких движений.

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

Владимир Бегун

- поедут планы запросов...

Если быть аккуратным с индексами - только для QUERY REWRITE. Которая в типичной OLTP, назовем так, используется мало.

Владимир Бегун

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

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

Владимир Бегун
то решение с exception table -- будет не тем быстрым, которое ищется...

Хм. Вот тут с удовольствием выслушаю. Знаешь метод быстрее exception table?

Владимир Бегун

Меняй пример или формулируй чётко,

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

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

Владимир Бегун

да и на счёт "врете"... :-) это ты
погорячился. Человек сделал правильные выводы из того что ты сказал,

"Врете" относилось не к выводам (или не столько к выводам), сколько ко вполне конкретным утверждениям.

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

Владимир Бегун

поскольку твоя "высосаная из пальца" задачка ничем не лучше оригинального
вопроса о выборке.

Не лучше в том плане, что в жизни мероприятия по восстановлению следовало бы начать с увольнения админов :) И ты прав в том, что задача высосана из пальца; я собирался исключительно показать, что переход между "совершенно абстрактной" и "достаточно реальной" задачами весьма невелик.
6 апр 05, 16:03    [1446100]     Ответить | Цитировать Сообщить модератору
 Re: SQL тест'ик - прислали до собеседования  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
MasterZiv
Насчет требований "на стандартном SQL". Если я тестирую товарисча, а он мне пишет например на DB2-шном (или это Оракл ? но не

А Вы пишете на стандартном SQL? Я пойму, если Вы будете требовать знания конкретно, например, Informix. По моему опыту, хороших специалистов стоит брать всегда - даже если они информикса не знают. Как понять, хороший ли специалист? Неформализуемо в общем случае; это одна из задач, за которые любой начальник в конечном итоге и получает свои большие деньги. Надеюсь, незачем говорить, что в детальных технических знаниях начальник вряд ли угонится за квалифицированными подчиненными - то есть задача такой оценки будет стоять у него постоянно.

MasterZiv
Как он будет работать, если он тривиальный запрос (других на собеседовании быть не может) не может написать без этой его фичи ?

Если он хороший специалист - будет работать, без проблем. Может ли он написать без этой фичи - а хз, Вам это и надо выяснить.
6 апр 05, 16:09    [1446121]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Работа Ответить