Witam Szanowne Grono!
Tworzę bazę danych do przechowywania informacji o czasie pracy pracowników. Suszę głowę o najlepsze, najbardziej optymalne rozwiązanie.
Chodzi tu głównie o funkcje daty i czasu (szczególnie czasu).
Otóż baza ma przechowywać godziny wejść i wyjść pracowników. Pracownik może opuszczać miejsce pracy kilkukrotnie w ciągu dnia.
Jest tabela z usr i opjce pozostałych:
1.
WEJSCIA
| ID | ID_USR | DATE | TIME |
WYJSCIA
| ID | ID_USR | DATE | TIME |

2.
WEJSCIA
| ID | ID_USR | DATETIME |
WYJSCIA
| ID | ID_USR | DATETIME |

3.
LOGI
| ID | ID_USR | DATETIME_WE | DATETIME_WY |

To takie pierwsze 3 pomysły;)
1. 2. - dają możliwość dodania jakiś info do danej akcji (np spóźnienie, wyjazd na delegację itd) 3 już nie (chociaż można dodać pole UWAGI i tam to opisać;)

Bardzo ważnym elementem jest wyliczenie czasu pracy na każdy dzień, tydzień, miesiąc, rok...

Wyliczenie jest banalne (godzina wyjscia - godzina wejscia) = czas pracy;) Chodzi mi tu o format przechowywania tych dat.
1. Czy lepiej przechowywać oddzielnie date, oddzielnie godziny?
2. Czy czas razem - wtedy jaki format okaże się najlepszy (DATETIME, TIMESTAP)?
2. Czy zapisywać oddzielnie wejscia i wyjścia, czy trzymać to w jednej tabeli?

Wymyśliłem, że można użyć TIMESTAP, dodatkowo ustawić DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, żeby w skrypcie i zapytaniu do bazy mieć jeden element mniej.

Jak się mają typy do wydajności przeliczania.
Bo w wyniku chciałbym np otrzymać tabele z danego dnia:
| Imie nazwisko | godzina wejscia | godzina wyjscia | czas pracy |
Jeśli dane będą przechowywane jako typ time, to 2,3 kolumna pozostaje bez zmian z bazy, tylko trzecią trzeba przerobić np:
SEC_TO_TIME( TIME_TO_SEC( WYJSCIA`.`TIME` ) - TIME_TO_SEC( `WEJSCIA`.`TIME` ) ) AS `CZAS_PRACY`

W przypadku użycia TIMESTAP, czy DATETIME trzeba przeliczać dla wszystkich pól...

Jak różne opcje będą się miały do wielokrotnych wejść? 2 oddzielne tabele - logowanie we/wy sprowadza się do prostego INSERT'a. 1 tabela powoduje, że przy wyjsciach trzeba robic update (Np UPDATE LOGI SET `DATETIME_WY`=now() where ID_USR=1 AND DATETIME_WY IS NULL;)

Co myślicie, może macie własne doświadczenia, pomysły, swoje wypracowane sposoby radzenia sobie w takich sytuacjach?
Pozdrawiam

Tam gdzie ja robię mamy dwie tabele jedna to mniej więcej Twoje logi tylko dodane pole "zdarzenie" i nie ma pola data_wyjscie Wszystko jest załatwiane polem zdarzenie natomiast druga to tabela zdarzenia

ZD_ID | ZD_Opis

załatwiasz to za każdym razem insertem. Co do przechowywania do chyba TIMESTAMP będzie najlepszy łatwo to potem w programach obrabiać.

Tutaj się to sprawdza a system jest rozłożony na parę miast. Myślę, że to dość optymalne rozwiązanie

mozesz jeszcze zrobic taka tabele

ID, IDUSER, DATETIME, TYPE, DESCRIPTION

gdzie TYPE to IN lub OUT:)
za kazdym razem jak pracownik wchodzi dodawany jest nowy wiersz do tej tabeli z typem in, jak wychodzi z typem out. dodatkowo w kolumnie description mozna wpisac ze wychodzi na spotkanie z klientem.

jako typ danych zastosowalbym DATETIME - mozna latwo wyliczac rozne rzeczy bezposrednio z poziomu mysql - do php zwracasz gotowe wyliczenia.

pozdrawiam

Tak sie zastanowiłem, i rzeczywiście trzymanie wyjść i wejść w dwóch oddzielnych tabelach nie ma sensu. Lepiej jedna a w niej dodatkowe pole z info która akcja we/wy.

ID | ID_USER | DATA | TYPE | DESCRIPTION |

No i typ daty będzie TIMESTAP (DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) - dzięki temu w zapytaniu nie trzeba podawać daty, i dodatkowo nikt nie może 'poprawić' godziny we/wy.