Zeiterfassung in DB, generelle Vorgehensweise?

[guidok]

Zitat:

Wenn man das Datum als "Date/Time" Wert speichert, muss bei Zeitraumvergleichen auch immer das Datum mit angegeben werden. Finde ich recht unpraktisch. Daher werde ich die Zeiten wohl als Float speichern.

Du kannst doch aus dem DateTime den Date oder die Time extrahieren, dann musst du nichts mit angeben. Alles andere hat Alzaimar schon gesagt.

[stahli]

eigentlich gehuppt wie gesprungen

Man muss in jedem Fall irgend etwas umrechnen oder umformatieren.
Wenn man DateTime für die Verwaltung von xx Minuten verwendet sieht das zumindest in eine TTable nicht sehr geschickt aus.

Aus jetziger Sicht würde ich daher für Dauer-Daten (die sich nicht über Tage und Monate erstrecken) Minuten oder Sekunden in Integerfeldern speichern.

[grenzgaenger]

sag mal, weshalb nimmste nicht 'n (modified) julian date(time) oder 'n UNIX date(time)? da kannste einfach rechnen und biste immer auf der sicheren seite ...

[guidok]

Ich kann auch nur sagen wie ich es machen würde und TTable kommt bei mir eh nicht ins Haus. Ist ja wohl ein leichtes aus einer Query die Daten auszulesen und selbst in ein entsprechendes Control zu bringen.

Zitat:

Aus jetziger Sicht würde ich daher für Dauer-Daten (die sich nicht über Tage und Monate erstrecken) Minuten oder Sekunden in Integerfeldern speichern.

Letztendlich gibt es hier keine "Dauer-Daten" sondern Beginn- und Endezeiten und ich habe heute morgen am 12.1007 um 6:23 Uhr mit der Arbeit begonnen. Merkst du was?

[stahli]

@grenzgaenger

Ich weiß jetzt nicht, was Du meinst.
Ich habe damals die BDE genutzt und jetzt FB.


@guidok

Ja klar, in dem eigenen Programm wird man die Ausgabe immer formatieren. Bei Einsicht in die Datenbank (z.B. mit einer DBConsole) werden Inhalte von DateTime-Feldern aber auch entsprechend formatiert. Das fände ich schon störend, wenn es sich nicht wirklich um ein Datum und eine Uhrzeit handelt.

In meinem Stechkartenprojekt bin ich davon ausgegangen, dass hier "Überstunden" bzw. "Überminuten" (positive + negative) verwaltet werden sollen. Deshalb sollten diese Werte auch in Integerfeldern stehen. Die kleinste Einheit ist in dem Fall eine Minute.
Hier interessieren weniger die einzelnen Uhrzeiten sondern das Saldo am Ende. Die Soll-Arbeitszeit ist ja auch in Stunden+Minuten vorgegeben und nicht in einer Uhrzeit.
Klar, für den Arbeitsbeginn und das Arbeitsende kann man mit Datum+Uhrzeit arbeiten. Das macht schon Sinn.

Ich denke schon, es gibt mehrere Lösungen, die sich an Vor- und Nachteilen bzw. Aufwand alle nicht viel nehmen...

stahli

[Jelly]

Zitat von Salomon:

Für eine Zeiterfassung die "realtime" arbeitet solltet man es so machen wie du schreibst. In meinem Fall könnte jedoch ein User probieren einen Zeitraum doppelt zu belegen.

Wenn dem so ist, würde ich das auf jeden Fall von der Datenbank selbst blockieren lassen, wenn da unsinniges Zeug eingetragen wird, denn nur so kannst du sicher sein, dass nicht doch irgendwas eingetragen wird, was nicht soll. Ich würde einen Trigger auf die Tabelle setzen (sowohl ein Update als Insert Trigger), und im Trigger ein Rollback und ein RAISERROR machen (bei MSSQL), wenn sich Zeiten überschneiden. Rollback bricht den Insert oder Update ab, und das RAISERROR löst eine Exception im Delphi Client aus, die du schön sauber abfangen kannst.

[Reinhard Kern]

Zitat von Jelly:

Wenn dem so ist, würde ich das auf jeden Fall von der Datenbank selbst blockieren lassen, wenn da unsinniges Zeug eingetragen wird, denn nur so kannst du sicher sein, dass nicht doch irgendwas eingetragen wird, was nicht soll.
....

Hallo,

dem ganzen Konzept liegt schon ein grosses Vertrauen in die Mitarbeiter zugrunde, wenn jeder seine Arbeitszeitdaten nach Belieben selbst verändern darf - für ein industriell verkaufbares System würde ich grundsätzlich nur An- und Abmelden mit der Systemzeit zulassen, Korrekturen darf nur das Personalbüro (oder der Chef) durchführen. Nur für diese Eingriffe wäre eine Plausibilitätskontrolle notwendig.

Wenn jemand morgens um 7 kommt und feststellt, dass er offiziell seit gestern durcharbeitet, dann ab zum Chef und mit dem Aushandeln, was als gestrige Abmeldung nachgetragen wird. Solange der Sequenzfehler bestehen bleibt, gibts bei der Auswertung eine entsprechende Fehlermeldung.

Grundsätzliche Anmerkung:

Bei einer Zeiterfassung geht es um viel Geld und öfters mal auch um Auseinandersetzungen vorm Arbeitsgericht. Der Programmierer ist also gut beraten, wenn seine Daten und Auswertungen so gerichtsfest wie möglich sind. Mir wäre z.B. wohler, wenn irgendwo ein Drucker mit viel Papier mitläuft und druckt "Müller kommt 2007-10-13 7:45; Meier geht 2007-10-13 11:57;" usw.

Ausserdem bedarf sowas meiner Ansicht nach einer Vereinbarung mit dem Betriebsrat, ist aber nicht mein Fachgebiet.

Gruss Reinhard

[guidok]

Zitat:

Hier interessieren weniger die einzelnen Uhrzeiten sondern das Saldo am Ende. Die Soll-Arbeitszeit ist ja auch in Stunden+Minuten vorgegeben und nicht in einer Uhrzeit.
Klar, für den Arbeitsbeginn und das Arbeitsende kann man mit Datum+Uhrzeit arbeiten. Das macht schon Sinn.

Stimmt natürlich, dass hier eher das Saldo am Ende interessiert. Aber es geht doch in einer DB auch darum Daten nicht unbedingt doppelt und dreifach zu speichern. Mit der Start- und Endzeit kann ich den Saldo berechnen, also muss ich diesen nicht zusätzlich speichern.
Natürlich könnte man aus der Benutzereingabe auch gleich den Saldo speichern und nur diesen speichern, aber damit gehen (evtl.) Informationen verloren, nämlich die Start- und Endzeit und vielleicht brauchst du die irgendwann einmal, um etwas nachzuvollziehen.

Direkten DB-Zugriff würde ich hier nicht als Argument sehen. Der Zugriff soll über ein Frontend erfolgen und fertig.

Guido

[stahli]

Zitat:

Stimmt natürlich, dass hier eher das Saldo am Ende interessiert. Aber es geht doch in einer DB auch darum Daten nicht unbedingt doppelt und dreifach zu speichern. Mit der Start- und Endzeit kann ich den Saldo berechnen, also muss ich diesen nicht zusätzlich speichern.
Natürlich könnte man aus der Benutzereingabe auch gleich den Saldo speichern und nur diesen speichern, aber damit gehen (evtl.) Informationen verloren, nämlich die Start- und Endzeit und vielleicht brauchst du die irgendwann einmal, um etwas nachzuvollziehen.

Na ja, man muss ja mindestens einen "Eingangssaldo" speichern (wenn z.B. ein Beamter neu in unser Amt wechselt und Überstunden mitbringt). Ab dem Zeitpunkt kann man dann das Saldo ständig neu berechnen lassen. Nach 40 Dienstjahren hat das Programm dann aber viel zu tun
Daher wäre mindestens zum Monatswechsel sinnvoll einen neuen Saldo zu speichern und von diesem aus weiter zu rechnen. Wenn dieser durch einen Verantwortlichen bestätigt ist, können keine rückwirkenden Änderungen (über das Programm) vorgenommen werden.

Ich habe mich darüber hinaus entschlossen, die berechneten Zeiten auch für jeden einzelnen Tag zu speichern. Der Nutzer gibt seine Arbeits-Uhrzeiten (Arbeitsbeginn, Pausenbeginn, Pausenende, Arbeitsende etc.) ein. Das Programm berechnet die Istzeiten und Überstundensaldo... (und zwar immer für den gesamten aktuell eingestellten Monat, ausgehend vom Monats-Eingangssaldo und einen Übertrag zum nächsten Monat).

stahli

[mkinzler]

Grundsatz von relationalen Datenbanken: Mehrfachspeicherungen von daten (Redundanzen) vermeiden!