MSSQL Tabela - czas pracy, date, time - dobrze projektuje?

Witam Was,

Projektuję bazę danych, w której między innymi ma być przechowywany czas pracy (w każdym dniu) pracowników. System działać ma w ten sposób, że pracownik przy wejsciu i wyjściu musi "odbić" kartę - dzięki temu logowane są informacje na temat czasu pracy dla konkretnej osoby. Pomijając kwestie jak to wszystko ma działać, jak najlepiej zaprojektować tabelę przechowującą zdarzenia czasu wejscia i wyjscia? Na razie wygląda to tak:

Tabela Worktime:

Id_Employee - id konkretnego pracownika, to jest klucz główny w tabeli z pracownikami
TheDay - dzien w stylu 2009-04-11
Entry_Time - czas wejscia, np 0645
Exit_Time - czas wyjscia.
(pominąłem kilka nieistotnych tu kolumn)

Baza docelowo będzie postawiona na SQL Server 2000, a testuje na 2005 Express. Czy w tej bazie istnieje w ogóle typ DATE oraz TIME? W necie niby pisze, że tak, ale moja baza wywala błąd, że nie ma takiego typu.

Czy taka tabela będzie wygodna w późniejszej obsłudze? Przykładowo należy liczyć się z tym, że ktoś w czasie dnia mogł wejść i wyjść klika razy - co być może skomplikuje zapytania.

Pozdrawiam

W wersji 2000 jedyne typy dla czasu i daty to zdaje się datetime i smalldatetime.
Z tego, co wiem, to oddzielne date i time zostały wprowadzone dopiero w wersji 2008.

a co jeśli pracownik wejdzie dziś a wyjdzie jutro??

To co polecacie jako typy? W sumie wielkiego wyboru nie ma, trzeba będzie kombinować z tym co jest, więc jak? Jest sens wtedy trzymać datę w czasie wejścia i wyjścia?

MisiekD: Taka sytuacja nie zajdzie, nawet jeśli się nie "odbije" wychodząc to w polach czasu pracy będzie wartość null, wtedy taki ktoś udaje sie do admina, a ten "uzupełnia" dane pole, Podobnie przy wejściu, jeśli ktoś zapomni karty, to admin może go ręcznie wpisać.

miałem na myśli nocną zmianę

flatron napisał(a)

To co polecacie jako typy? W sumie wielkiego wyboru nie ma, trzeba będzie kombinować z tym co jest, więc jak? Jest sens wtedy trzymać datę w czasie wejścia i wyjścia?

Do takich zastosowań wystarczy chyba dokładność smalldatetime.

flatron napisał(a)

Taka sytuacja nie zajdzie, nawet jeśli się nie "odbije" wychodząc to w polach czasu pracy będzie wartość null, wtedy taki ktoś udaje sie do admina, a ten "uzupełnia" dane pole, Podobnie przy wejściu, jeśli ktoś zapomni karty, to admin może go ręcznie wpisać.

No to po cholerę w ogóle system informatyczny, skoro ktoś ma ręcznie wpisywać. Wystarczy maszyna do pisania ;P

Ja bym zrobił tak:
Id_Employee
Time smalldatetime - jasne
Type char(1) - czyli czy wejście (i) od in czy wyjście (o) od out

Wszystkie informacje z takiej tabeli wyciągniesz

Hallo flatron!

flatron napisał(a)

To co polecacie jako typy? W sumie wielkiego wyboru nie ma, trzeba będzie kombinować z tym co jest, więc jak? Jest sens wtedy trzymać datę w czasie wejścia i wyjścia?

1. Problem jaki typ zastosowac datetime czy smalldatetime jest troche dzieleniem wlosa na czworo. Mimo to musisz sie na jeden z nich zdecydowac. Ja pewnie zdecydowalbym sie na smalldatetime chociazby tylko dlatego, ze dodatkowe informacje zawarte w datetime (np. ulamkowe czesi sekundy) nie maja zadnego znaczenia w przypadku rejestracji czysu pracy.

2. Co do kolumn, to jako alternatywe do propozycji hyde'a mozna by bylo zdefiniowac dwie kolumny "przyjscie" (data i czas przyjscia) i "wyjscie" (data i czas wyjscia). Wydaje mi sie, ze dalsza obrobka danych bylyby w tym przypadku prostsza. Przy zapisie daty i czasu zdarzenia (przyjscie, wyjscie) unika sie problemu, ze czas pracy rozciaga sie na dwie daty (praca na zmiany). Teoretycznie pracownik moglby przyjsc do pracy we wtorek o 06:00 i wyjsc w piatek o 23:30. Czy taki wpis mialby sens? Pewnie nie, a moze tak? W kazdym przypadku z punktu widzenia bazy danych jest on formalnie poprawny. A o tym czy jest sensowny czy nie musialyby rozstrzygac funkcje kontrolujace wpisy do dazy.

Pozdrawiam
Markus
:-)

OK, po pierwsze - MisiekD ma rację. Co z pracą nocną?
Pisanie RCP na zasadzie: "Nie jest potrzebna" mija się trochę z celem, bo za kilka miesięcy klient może powiedzieć: "Jednak chciałbym pracę nocną", ale wtedy przeprojektowanie systemu to będzie masakra totalna.

No, chyba, że masz 10000% pewności, że klient nigdy nie będzie chciał pracy nocnej, ale wtedy musisz się liczyć też z tym, że aplikacji nie sprzedasz zbyt wielu klientom :)

Po drugie. Jaki typ. Ja stosuję DATETIME z tego względu, że SMALLDATETIME nie bierze pod uwagę sekund(tak wyczytałem w mądrych księgach), a ja sekund potrzebuję :)

Poza tym propozycja Hyde'a co do struktury tabeli może okazać się niewystarczająca. Ale to już zależy od założeń systemu i od tego, jak on jest zbudowany.