Sinnvoller aufbau einer DB

[Beach]

Hallo zusammen,

ich überlege nun seit einiger Zeit wie ich Sinnvoll eine DB aufbauen kann.

Das Ziel:
Tägliche Erfassung von Reise und Arbeitszeiten zu bestimmten Aufträgen von verschiedenen Mitarbeitern (derzeit etwa 5-10).
Später soll daraus der monatliche Stundenreport erzeugt werden.

Datenbank:
Derzeit zur Entwicklung SQLite3, aber diese soll später portiert werden auf (voraussichtlich) MariaDB
Daher Verwendung von UNIX Timestamp

Eingabe von:
Tag, Mitarbeiter (Personalnummer), Anreise (Anfang und Ende), Arbeitszeit (Anfang und Ende), Rückreisezeit (Anfang und Ende), Gesamtdauer Pausen und ob diese während der Anreise, Arbeits oder Abreisezeit gerechnet werden sollen (nur in einer dieser Zeiten), Urlaub, AZK Konto, Freizeitausgleich, Krankheit (jeweils ganzer oder halber Tag), Kunde (ID Nummer als Querverweis), Bemerkungen zu dem Tag

Meine Überlegung:
Alle Datum/Zeitangaben als entsprechender UNIX Timestamp.
"day" als UINX Timestamp 0 Uhr des jeweiligen Tages.
Urlaub, AZK Konto, Freizeitausgleich, Krankheit als 10facher INT Wert (5, 10 entspricht 0,5 bzw 1 Tag)

Code:

CREATE TABLE "worktime" (
   "id"   INTEGER PRIMARY KEY AUTOINCREMENT,
   "day"   INTEGER,
   "personal_number"   INTEGER,
   "travel_start"   INTEGER,
   "travel_end"   INTEGER,
   "work_start"   INTEGER,
   "work_end"   INTEGER,
   "travel_back_start"   INTEGER,
   "travel_back_end"   INTEGER,
   "break_travel_time"   INTEGER,
   "break_work_time"   INTEGER,
   "break_travel_back_time"   INTEGER,
   "day_off"   INTEGER,
   "work_time_comp"   INTEGER,
   "lieu_time_comp"   INTEGER,
   "company"   INTEGER,
   "remark"   TEXT
);

Was denkt Ihr, ist das ein Sinnvoller Aufbau?
Habt Ihr Vorschläge wie man es einfacher/besser/eleganter lösen könnte?
Oder würdet Ihr das ganze komplett anders angehen?

Bin gespannt auf eure Ideen, Vorschläge und Überlegungen.

MfG

Jürgen

[Sherlock]

Es gibt auch in RDBMS Datumstypen, warum etwas anderes verwenden? Das macht es doch nur unnötig komplex.
Und warum schon von vorneherein einen DB-Switch einplanen, wenn man gleich auf die End-DB setzen kann?

Sherlock

[haentschman]

Moin...

Zitat:

"personal_number" INTEGER,

Die Personalnummer hat in dieser Tabelle nichts zu suchen. Besser ein Schlüssel auf die Mitarbeitertabelle (z.B. ID_Employee)

[Beach]

Zitat von haentschman:

Moin...

Zitat:

"personal_number" INTEGER,

Die Personalnummer hat in dieser Tabelle nichts zu suchen. Besser ein Schlüssel auf die Mitarbeitertabelle (z.B. ID_Employee)

Die Personalnummer ist in dem Fall als Querverweis auf die Mitarbeitertabelle gedacht. Da diese eindeutig und dauerhaft einem MA zugeordnet ist.
Welchen direkten Vorteil hätte die Verwendung der ID anstelle der PersNR?

[stifflersmom]

Zitat von Beach:

Zitat von haentschman:

Moin...

Zitat:

"personal_number" INTEGER,

Die Personalnummer hat in dieser Tabelle nichts zu suchen. Besser ein Schlüssel auf die Mitarbeitertabelle (z.B. ID_Employee)

Die Personalnummer ist in dem Fall als Querverweis auf die Mitarbeitertabelle gedacht. Da diese eindeutig und dauerhaft einem MA zugeordnet ist.
Welchen direkten Vorteil hätte die Verwendung der ID anstelle der PersNR?

Eine Personalnummer "könnte" sich ändern durch Umfirmierung oder Ähnliches. Die ID in einer Tabelle normalerweise nicht

[mkinzler]

Die Tabelle ist auch recht unnormalisiert.

ich würde die ganzen Zeitspannen in eine Untertabelle ablegen.

[Beach]

@stifflersmom: Gutes Argument.

@mkinzler: Genau das ist der Grund warum ich nachfrage...
Kannst du das etwas näher aufschlüsseln wie du es machen würdest?

In einer Untertabelle einfach nur Anfangs und Endzeit (egal ob als Reise- oder Arbeitszeit) und das dann per ID-Verweis in der Haupttabelle entsprechend zuordnen für was?

[haentschman]

Moin...

Zitat:

Die Personalnummer ist in dem Fall als Querverweis auf die Mitarbeitertabelle gedacht. Da diese eindeutig und dauerhaft einem MA zugeordnet ist.

Da hat mit Sicherheit die DSGVO was dagegen.

[Beach]

Zitat von haentschman:

Moin...

Zitat:

Die Personalnummer ist in dem Fall als Querverweis auf die Mitarbeitertabelle gedacht. Da diese eindeutig und dauerhaft einem MA zugeordnet ist.

Da hat mit Sicherheit die DSGVO was dagegen.

Unschlagbares KO Kriterium.....

[jobo]

Normalisierung vielleicht eher so:
Was | Von | Bis | ..
----------------
Anreise| 2.1.2019 09:00 | 2.1.2019 09:30
Arbeit | 2.1.2019 09:30 | 2.1.2019 17:30
Pause | 2.1.2019 12:30 | 2.1.2019 13:15
..

Natürlich plus weitere notwendige Bezugsfelder.

Ob die DSGVO was gegen die Personalnummer dabei hat, weiß ich nicht. Man verwendet jedenfalls keine fachlichen Werte als Schlüssel, höchstens als Referenz. Irgendwie muss am Ende ja kenntlich sein, um welche Mitarbeiter es geht.

Und ja, man würde nicht alles in irgendwelchen seltsamen Zeiteinheiten halten, sondern ein Datetime Wert nutzen.

Und wenn es eine allgemeine Zeiterfassung werden soll, müsste man das Datenmodell vielleicht noch darauf abklopfen, wie es sich für nicht-Reisetätigkeiten eignet.

Wenn es für eine mobile Tätigkeit und Nutzung gedacht ist, sollte die Plattform vielleicht auch für einen Mobilen Einsatz taugen.