![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Помогите вычислить промежуток времени между двумя записями в базе [D7, MSSQL]
Sens © (2004-04-13 08:34:00)Помогите!!! Работаю над программой отчетов по электронным проходным, не знаю как сделать учет рабочего времени за день (хотябы за день). Когда человек проходит через проходные в базе регистрируется его номер направление и время прохода, за день таких регистраций может быть очень много (если например человек бегает по вызовам), а мне нужно получить сумму времени, которую человек провел в центральном здании, или хотябы время между первой (входной) и последней (выходной) регистрацией человека. Пока не знаю как запрос организовать, и при этом, чтобы он выполнялся быстро. Если есть идеи - помогите.
Anatoly Podgoretsky (2004-04-13 10:44:00) [21]Nikolay M. © (13.04.04 10:20) [14]
Какие многоэтажные запросы, просто bwtween d1 and d2, индексы будут учитываться, по его данным это примерно 6000 записей на месяц.
Sergey13 (2004-04-13 10:40:00) [22]2Sens © (13.04.04 10:28) [15]
>но я пока планирую сделать не много
Так, скорее всего не получится. Или все или ничего. Прикинь, чела вызвали в военкомат, например. Это ГО (гособязанность)-оплата 100%. Больничные, отгулы (с документальным подтверждением), уходы по производственным делам и т.д. и т.п. Без таких вещей твой табель нужен только в туалете, если конечно бумага мягкая. 8-)
А кроме всего прочего (у нас железо самой проходной доисторическое), бывает что данных просто нет в принципе. Зимой замерзло, летом вспотело. 8-) А люди то ходят, и что самое удивительное - некоторые работают.
>У наших расчетчиков учитываются отработанные часы/мес.
Добавь сразу возможность ручной корректировки результатов, 8-) иначе... 8-(
Sens (2004-04-13 10:28:00) [23]2 Anatoly Podgoretsky
Да, логика будет сложная, но я пока планирую сделать не много... учет за день, а потом вывести в отчет дни за месяц, повыбрасывав из них выходные и праздничные дни (это и будет табель выходов на работу). У наших расчетчиков учитываются отработанные часы/мес.
Последую примеру и буду логику делать на клиенте.
Спасибо Всем за идеи. ;)
Nikolay M. (2004-04-13 10:20:00) [24]Правильнее писать эн-этажные тормозные запросы, для которых каждый раз будет подниматься план выполнения и в котором почти наверняка не будут использоваться индексы, гонять данные по сети и загружать всяким барахлом клиента.
Anatoly Podgoretsky (2004-04-13 10:16:00) [25]Не дело сервера заниматься логическими вычислениями.
Nikolay M. (2004-04-13 10:14:00) [26]
> логику делать на клиенте.
на фига??? По шее потом получить?
Anatoly Podgoretsky (2004-04-13 09:54:00) [27]Ты учитывай и непарность
IN,OUT,IN,IN,IN,OUT,IN,OUT,OUT,IN
И переход через сутки, месяц, а у тебя еше и тип входв/выхода, может оказаться - обед выход, пришел на работу
Различные графики работы, логика может оказаться очень сложной, придется применять ИИ, а то у тебя очень такая красивая табличка :-)
Что такое 900 000 записей, мелочь, работать то наверняка будешь с интервалом дат и логику делать на клиенте.
Order by klient, date
Nikolay M. (2004-04-13 09:47:00) [28]Имхо, не стоит мудрить, пытаясь достать эту сумму одним запросом. Лепил я в целях повышения образованности такие десятиэтажные запросы, где одна таблица джойнилась сама на себя раз 5 + куча CASE-ов. И не факт, что в итоге получится правильно.
Имхо, небольшая хранимая процедурка + курсор на SELECT, в котором данные отсортированы по дате входа/выхода + несколько IF-ов - как раз то, что нужно.
Sergey13 (2004-04-13 09:46:00) [29]2Sens © (13.04.04 09:35) [8]
>если в этой таблице уже почти 900 000 записей...
Ну дык, чисти ее. Кому нужен прошлогодний снег? На крайний случай скидывай "месячные итоги" в архивную таблу и чисти оперативную.
Sens (2004-04-13 09:35:00) [30]Вот и я о том-же сделать можно, но представите сколько прога быдет все это вычислять для того, чтобы сделать табель выходов на работу за месяц для 1400 человек, если в этой таблице уже почти 900 000 записей...
Вот и написал посоветоваться, одна голова хорошо, а форум лучше :)))
Горе мне - горе...
:))
Sergey13 (2004-04-13 09:31:00) [31]ИМХО, "стандартными" запросами тут не пройдет. Надо писать программу - логика там больно неопределенная, вернее условий сильно много (например чел в отпуске и зашел на полчаса деньги получить). А в таблице с проходами можно выставлять флажок - запись уже обработана да/нет.
Sens (2004-04-13 09:15:00) [32]==========================================================
1 2 3 4 5 6 7
1144 | 1 | 1 | 1| 0 | 0 | 2003-10-22 07:15:00 - пришел на работу
1144 | 1 | 1 | 0| 0 | 0 | 2003-10-22 12:02:45 - обед выход
1144 | 1 | 1 | 1| 0 | 0 | 2003-10-22 12:56:17 - обед вход
1144 | 1 | 1 | 0| 0 | 0 | 2003-10-22 17:02:51 - ушел с работы
==========================================================
1 colAccountNumber - ключ, номер человека
2 colCardholder
3 colPointNumber
4 colDirection - направление прохода
5 colZoneTarget - куда вышел
6 colStatusNumber - статус (разрешен ли доступ или отказано по какой-то причине)
7 colRegistrationTime - время регистрации
Проблема какраз состоит в том, чтобы выбрать 1-ю и последнюю запись. Понятно что можно вызвать запрос, со всеми тегистрациями, взять прервую запись и последнюю запись в из результата, это получится время прихода и ухода, а как выкинуть время обеда ???
Sergey13 (2004-04-13 09:04:00) [33]2Anatoly Podgoretsky © (13.04.04 08:52) [3]
"Та заводская проходная, что в люди вывела меня", написанная мной на Клиппере, крутится уже 12 лет. Не далее как час назад "пробился" на входе. Там очень дофига"если бы да кабы", но именно поэтому я и написал " нечто вроде". У меня например сначала идет проверка на "парность" вход/выход. Далее эти записи (нарушители проходного режима) в расчете не учавствуют, точнее по ним расчитывается время нарушения (тоже кстати с большими допущениями из-за неопределенностей).
sniknik (2004-04-13 08:57:00) [34]может и получится
select sum(Case номер направление when 0 then -1 else 1 end * время прохода) FROM Table1
(вариацию с приведением типа лутше сделать, это только идея) ну и подумать на тему если чел в ночную работает, сегодня пришол завтра ушол (через дырку в заборе ;о)) а данные по дню групируются...
Anatoly Podgoretsky (2004-04-13 08:52:00) [35]ЮЮ © (13.04.04 08:45) [1]
В реальности для проходных такое точное соответствие не всегда бывает. А второй вариант первой (входной) и последней (выходной) вообще бессмысленный - вошел 2.01.2001, выше 13.04.2004. Какой то смысл появляется если применить формулу последней входной и последней выходной, предпоследней входной и предпоследней выходной и так далее.
Несложно организуется проходом по двум наборам данным - входа и выхода.
ЮЮ (2004-04-13 08:45:00) [36]>и при этом, чтобы он выполнялся быстро
Для этого каждая запись "выхода" должна ОЗНОЗНАЧНО соответствовать записи на "вход". Тогда, соединив через JOIN, получим пары вход-выход. Естественно, лучше организовать на уровне структуры данных
Sergey13 (2004-04-13 08:45:00) [37]Вообще, не дурно бы знать как ты хранишь все это добро, но нечто вроде
select max(time_field)-min(time_field) FROM Table1
where....
даст тебе разницу.