Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Помогите вычислить промежуток времени между двумя записями в базе [D7, MSSQL]


Страницы:   1 2

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....
даст тебе разницу.


Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо