как эта задачка решается Хорошо?

← →
картман © (2011-06-23 17:33) [0]

табличка:
tOper:
group_id, cnt, oper, date

cnt: количество
oper: 0 - приход, 1 - расход

надо получить нд вида:
группа, входящий остаток, приход за период, расход за период;
параметры: начало периода и конец.
Писать на SQL. За один проход по таблице.

написал так:

select group_id,
sum(case when date < BeginDate then
case when oper = 0 then cnt
else -cnt
end
else 0
end) [входящий остаток],
sum(case when date >= BeginDate and oper = 0 then cnt
else 0
end) [приход],
-"- oper = 1 -"- [расход],
from tOper
where date <= DateEnd
group by group_id

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

← →
ЫЫАААвот (2011-06-23 21:43) [1]

Через join.

← →
картман © (2011-06-23 22:29) [2]

> Через join.

да эт понятно, но условие:

> За один проход по таблице.

- хотя я не знаю, join сама к себе - один проход?

← →
sniknik © (2011-06-23 23:54) [3]

> За один проход по таблице.
может ожидали цикл по курсору с формированием нужного/результирующего рекордсета "вручную".
так будет очевидный 1 проход... не факт что более быстрый чем запрос, даже с джойном, но очевидный.

← →
картман © (2011-06-24 00:13) [4]

> sniknik © (23.06.11 23:54) [3]

> не факт что более быстрый чем запрос, даже с джойном, но
> очевидный.

да явно медленнее будет... ну и в описании задачи: "написать на SQL" - как еще это можно понять?

← →
sniknik © (2011-06-24 00:45) [5]

> написать на SQL
ну так... а это что не sql?

(пример из BOL)
USE pubs GO DECLARE authors_cursor CURSOR FOR SELECT au_lname FROM authors WHERE au_lname LIKE "B%" ORDER BY au_lname OPEN authors_cursor -- Perform the first fetch. FETCH NEXT FROM authors_cursor -- Check @@FETCH_STATUS to see if there are any more rows to fetch. WHILE @@FETCH_STATUS = 0 BEGIN -- This is executed as long as the previous fetch succeeds. FETCH NEXT FROM authors_cursor END CLOSE authors_cursor DEALLOCATE authors_cursor GO

может поэтому и не взяли?

← →
картман © (2011-06-24 01:04) [6]

> ну так... а это что не sql?
>
> (пример из BOL)

это ж T-SQL

← →
Компромисс (2011-06-24 11:08) [7]

Может, они хотели исключить те группы, по которым не было движения за указанный период? Тогда еще having надо было бы добавить.

Кстати, что значит через join в данном случае? Не представляю, как он тут может помочь...

← →
картман © (2011-06-24 11:20) [8]

> Тогда еще having надо было бы добавить.

для краткости я сюда не стал это включать, а так было

> Кстати, что значит через join в данном случае?

по одному соединению посчитаем входящий остаток, по другой приход/расход, в where ограничения: t1.date < DateBegin and t2 between DateBegin and DateEnd - не надо будет каждый раз в select"e в case проверять дату

← →
Компромисс (2011-06-24 11:50) [9]

> по одному соединению посчитаем входящий остаток, по другой
> приход/расход, в where ограничения: t1.date < DateBegin
> and t2 between DateBegin and DateEnd - не надо будет каждый
> раз в select"e в case проверять дату

Все равно не до конца понимаю.

select ...
from tOper before join tOper period on (period.group_id = before.group_id)
where before.date < BeginDate
and period between BeginDate and EndDate
...

Так, что ли? Я думаю, одна дополнительная проверка даты выполнится гораздо быстрее, чем join. Умные СУБД заметят, что одно и то же условие встречается в нескольких местах.

← →
картман © (2011-06-24 12:22) [10]

> Так, что ли?

да

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

наверное

Что за контора, если не секрет, и что за вакансия?

← →
Компромисс (2011-06-24 13:05) [12]

картман © (24.06.11 12:22) [10]

Понятно, спасибо.
Странные работодатели ИМХО. У Вас вполне хороший код получился. Если какая-то ошибка и была (или вообще нужно было другую идею использовать), то нельзя отказывать только из-за этого. Мне это напомнило одно java-собеседование, где у меня спрашивали, чем final Integer a = 15 отличается от final Integer b = 150000.
Такое впечатление, что интервью проводил не совсем квалифицированный сотрудник, который зациклен.

> Компромисс (24.06.11 13:05) [12]

> Странные работодатели ИМХО.

да и задачка слишком уж простенькая - что с ее помощью можно выяснить? К тому ж, давали час на решение))

← →
Компромисс (2011-06-24 14:12) [15]

да и задачка слишком уж простенькая - что с ее помощью можно выяснить? К тому ж, давали час на решение))

Ну, задачка не совсем уж простая, позволяет оценить навыки. Хотя час - слишком много, согласен. ИМХО более полезным оказывается наблюдать за процессом решения задачи, это позволяет лучше оценить соискателя. Смотреть, как человек мучается целый час, я бы не смог :)

как эта задачка решается Хорошо? Найти похожие ветки