|
Datenbank: SQLite • Version: 3 • Zugriff über: ZEOS
Sinnvoller aufbau einer DB
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:
Was denkt Ihr, ist das ein Sinnvoller Aufbau?
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 ); 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 |
AW: Sinnvoller aufbau einer DB
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 |
AW: Sinnvoller aufbau einer DB
Moin...:P
Zitat:
|
AW: Sinnvoller aufbau einer DB
Zitat:
Welchen direkten Vorteil hätte die Verwendung der ID anstelle der PersNR? |
AW: Sinnvoller aufbau einer DB
Zitat:
|
AW: Sinnvoller aufbau einer DB
Die Tabelle ist auch recht unnormalisiert.
ich würde die ganzen Zeitspannen in eine Untertabelle ablegen. |
AW: Sinnvoller aufbau einer DB
@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? |
AW: Sinnvoller aufbau einer DB
Moin...:P
Zitat:
|
AW: Sinnvoller aufbau einer DB
Zitat:
|
AW: Sinnvoller aufbau einer DB
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. |
AW: Sinnvoller aufbau einer DB
Zitat:
 Passierschein A38 auch gleich dazu.Die DSGVO macht IMHO keine Vorschriften bzgl. Datenmodell sondern der Möglichkeiten der Einsichtnahme und Übermittlung. |
AW: Sinnvoller aufbau einer DB
Die Day-Spalte würde ich mir auch schenken und den Tag aus der Startzeit ermitteln. Das allerdings bedeutet, dass Du keine Zeiträume über den Tageswechsel hinaus eintragen kannst, sondern selbst dafür sorgen musst, um 23:59:59 zu stoppen und dann um 00:00:00 wieder zu starten. Auch würde ich die Arten nicht über einen String sondern auch wieder über eine ID aus einer anderen Tabelle referenzieren (WorkTypes).
WorkTypeID 1 / Work 2 / Travel 3 / Pause ... employe_id / Worktype / Start / End 1 / 1 / 01.01.2019 22:00:00 / 01.01.2019 23:59:59 1 / 1 / 02.01.2019 00:00:00 / 02.01.2019 04:15:00 |
AW: Sinnvoller aufbau einer DB
Schau Dir mal
Kimai an. Das macht genau diese Erfassung für Dich und Dein Team und ist einfach aufzusetzen.Wenn Du es in Delphi dennoch programmieren möchtest, kannst Du Dir ja deren Datenbankdesign einmal anschauen. Grüße, Christoph |
AW: Sinnvoller aufbau einer DB
Kimai ist ein sehr interessantes Projekt. Wenn ich mir es auch momentan nicht vorstellen kann das es für unsere Tätigkeiten passt.
Um an das DB Design zu kommen müsste ich es leider zuerst installieren. Da habe ich im Moment keine Gelegenheit zu. Aber mir geht es auch eigentlich auch darum ein eigenes Projekt zu haben, um zu lernen. Wenn es dann einen Nutzen für mich hat, umso besser. Daher vielleicht mal als kleine Erklärung der Hintergründe (für diejenigen die es Interessiert. Andere einfach überlesen bitte) ;): Was mir so als "Komplettanwendung" durch den Kopf geistert wäre das Erstellen von Serviceberichten / Hallenberichten (das was in der Firma gearbeitet wird) und das automatische Einfügen der Arbeitszeiten in die DB, so das am Monatsende der monatliche Stundenbericht für die Personalabteilung und für unsere Reisekostenabrechenung (in sehr vereinfachter Form) erstellt werden kann. Diese Sachen werden bei uns momentan komplett über verschieden Excel Tabellen händisch gepflegt. Braucht man wohl nichts weiter dazu zu sagen. Hat man die Daten aber erstmal in einer DB, kann man sich vieles erleichtern damit. Nun bin ich aber was das Thema Programmieren angeht noch absoluter Anfänger. Habe zwar vor Jahren mal öfters mit PHP Scripten zu tun gehabt, daher kommen auch Grundkenntnisse im Bereich Datenbanken, wenn dieses auch stärker eingerostet sind als ich gedacht habe. Ansonsten ist das alles recht neu für mich. Daher versuche ich Momentan erstmal Umsetzungen in kleinen Teilbereichen, auch um halt vieles erstmal zu lernen. Aber mit dem Augenmerk das ganze irgendwann mal zu einem großen zusammen zu bringen. Daher auch die Überlegung auf ein RDBMS zu wechseln. Denn sonst würde SQLite mir bis auf weiteres erstmal reichen. Ich will nicht zu viel auf einmal angehen Für mich sonst wächst mir das schnell über den Kopf. Meine erster Teil aus diesem "Projekt" war das Thema "Hallenberichte", der Überschaubarste Teil. Das ganze habe ich auch hinbekommen das es soweit das macht was ich mir darunter vorgestellt habe. Allerdings alles nach dem Motto "Hauptsache es funktioniert". Als Anfänger braucht man schließlich Erfolgserlebnisse. Verbesserungspotenzial in allen Bereichen ist noch zur Genüge vorhanden. Warum dann nicht diesen Bereich erstmal auf Vordermann bringen? Naja, die Ursprüngliche Idee ist halt die Zeiterfassung (manuell) und das Erstellen des monatlichen Stundenbericht. Deshalb würde ich gerne mit diesem Teil weitermachen. Zeiten und Angaben eingeben, vergleichbar mit unserer Excel Tabelle (genaugenommen ist es eine OOo Calc Tabelle) und als Ergebnis den Ausdruck für die Personalabteilung und ein paar Statistiken für mich selber. Alle anderen Ideen ist erstmal Nebensächlich.... Dabei dann auch Prgrammtechnisch besser/sauberer werden. |
AW: Sinnvoller aufbau einer DB
Anmerkung zur Personalnummer:
Auch wenn sie meist nur aus Ziffern besteht, ist sie keine Zahl (führende Nullen) Gruß K-H |
AW: Sinnvoller aufbau einer DB
Zitat:
Vielleicht gibt es Handlingargumente, aber ich hoffe, es bleibt nicht am Mitarbeiter hängen, diese Angaben zu tätigen. |
AW: Sinnvoller aufbau einer DB
Hallo,
Zitat:
wenn jemand über Mitternacht weg ist, macht das Aufdröseln bei 23:59:59 nicht viel Sinn (wo bleibt dann übrigens die 1 Sekunde?). Ich hatte das damals mal so gemacht, dass es ein Startdatum, aber kein Enddatum gibt. Die Zeit selbst wurde komplett auf das Startdatum gerechnet. |
AW: Sinnvoller aufbau einer DB
Wie gesagt, es ging mir um die Day-Spalte, die anfangs aufgezählt war, und da macht es meiner Meinung nach schon Sinn, den Tageswechsel zu beachten, damit in Summe keine stundenzahl von über 24 für einen Tage ermittelt werden kann
|
AW: Sinnvoller aufbau einer DB
Zitat:
Tatsächlich sollte m.E. grundsätzlich aber besser das abgespeichert werden, was stattgefunden hat, statt proaktive Korrektur eines hypothetischen Auswertungsfehlers. Man kann ja anhand der Daten bei Bedarf dann ermitteln, ob ein Tageswechsel dabei war. Auswertungen bzw. allgemeine Verwendung dieser Daten würde wahrscheinlich sowieso im Rahmen eines existierenden Schichtmodells erfolgen, wenn tatsächlich zu solchen Zeiten gearbeitet wird. |
AW: Sinnvoller aufbau einer DB
Liste der Anhänge anzeigen (Anzahl: 1)
Also zu dem Thema Tageswechsel...
Es kommt durchaus öfters vor das wir über den Tageswechsel unterwegs sind (Reisezeiten). Dazu habe ich im Moment aber noch keine wirklichen Gedanken gemacht. Muss ich auch noch nachholen. Auf jedenfall habe ich mir den Aufbau noch einmal gründlich durch den Kopf gehen lassen. Bin aber immer noch nicht ganz überzeugt.... Im Anhang ein Bild eines ER-Diagramms, um das Prinzip zu verdeutlichen. In der wt_time_sub sollen alle Zeiten gesammelt werden. Als Typ geb ich an um welche Art es sich handelt z.B. Arbeitszeit oder Urlaub Nun brauche ich aber eine Beziehung zur Tabelle wt_time_main um die Zeiten einem Tag und einem MA, usw zuzuordnen.. Das, habe ich gedacht über einen numerischen Schlüssel zu machen (Spalte key_time in Tabelle wt_time_main bezieht sich auf Spalte key in Tabelle wt_time_sub). Dieser Schlüsselwert kommt aber in der wt_time_sub mehrfach vor (es können mehrere Einträge pro Tag und Person sein) Könnte man das so lösen, oder gibt es eine andere Möglichkeit mehrere Werte in einer Tabelle eindeutig einer Spalte in einer anderen Tabelle zuzuordnen? PS: Die Beziehungen zwischen wt_time_main zu wt_time_Sub und wt_expenses sind in der Grafik nicht korrekt dargestellt. OOo Base hat da gemeckert wegen FK.... |
AW: Sinnvoller aufbau einer DB
Du müsstest die 1:n Beziehung umdrehen.
1 Main Eintrag hat mehrere Sub Einträge. P.S: Ich bin mir nicht ganz sicher, ob Dein Main Sinn macht, es kommt mir so vor, also sei es gedanklich aus einer "Reise" enstanden, also sozusagen auf Basis einer Reisekostenabrechnung. Das muss nicht schlimm sein, Du hast ja noch weitere Pläne und willst kontinuierlich erweiteren und umbauen... |
AW: Sinnvoller aufbau einer DB
Test
|
AW: Sinnvoller aufbau einer DB
Zitat:
Problematisch könnten Fehleingaben mit Zeitüberschneidung werden. Gruß K-H |
AW: Sinnvoller aufbau einer DB
Liste der Anhänge anzeigen (Anzahl: 1)
Ich glaube nun habe ich's verstanden mit den Beziehungen. :?
Danke soweit für eure Infos und Geduld. Wobei jetzt die Überlegung weitergeht wenn man über Mitternacht unterwegs ist.... Bei dem momentanen Modell bleibt, wenn ich das richtig sehe, nur der Split nachts um 24 Uhr. |
AW: Sinnvoller aufbau einer DB
Zitat:
|
AW: Sinnvoller aufbau einer DB
Zitat:
Auch wenn in einem Betrieb Reisetätigkeiten erfolgen, was ist nachts um 24 Uhr meist los? Schläfchen? ... Soll das wirklich in die Zeiterfassung? Und selbst wenn ja und oder wenn es kein Schläfchen ist, sondern Arbeit, warum nicht als Ganzes? Wie bereits angedeutet, wenn es sich hier um das Berufsfeld Ärzte, Lokführer, Capitäne usw. handelte, wäre sowieso ein Schichtmodell am Start mit entsprechender Software und Datenmodell. Und die Datentypen haben damit bestimmt kein Problem, ein Tag plus Uhrzeit, kein Problem. Man kann wunderbar damit rechnen und hat erstmal kein Darstellungsproblem, wenn man auf die Rohdaten schaut. Wieso wollte man hier immer doppelt Einträge sehen um Mitternacht? |
AW: Sinnvoller aufbau einer DB
Es gibt noch andere Branchen die zu Unzeiten unterwegs sind.
Wir sind Serivcetechniker im Außendienst und das Weltweit. Da kommt dann eigentlich nicht nur das "Problem" das es über Mitternacht geht, sondern auch noch das "Problem" das ich Zeitverschiebungen habe. Da wir allerdings nicht täglich durch die Weltgeschichte reisen, haben wir es bis jetzt so gehalten das die Zeitzone des Abreiseortes beibehalten wurde und der erste Arbeitstag in der neuen Zeitzone dann in lokaler Zeit angegeben wurde. Aufgrund der geforderten Ruhepause von min 10h gab es so keine direkte Überschneidung bei diesem System. Bis jetzt. Wenn ich als Start und Endzeit in der wt_time_sub ein volles Datetime nehme, dann habe ich aber zumindest das Problem mit dem Tageswechsel erledigt. Dann brauche ich auch die Spalte "day" in der wt_time_main nicht und nehme den Tag aus der "Startzeit" ?¿? :gruebel: :gruebel: Zu dem Problem mit den unterschiedlichen Zeitzonen, könnte man das umgehen in dem man alle Zeiten in UTC speichert und bei der Ausgabe entsprechend wieder in lokale Zeit umrechnet? So hätte man für den Bericht alles in local time, aber die Gesamtstunden, abgeleitet von der UTC, würden passen.... :gruebel: Macht das Sinn? Kommt nicht regelmäßig, aber doch immer wieder vor. |
AW: Sinnvoller aufbau einer DB
- Wenn alle Tabellen mit wt_ anfangen, kannst du das auch weglassen.
- Ich würde nicht alle PKs ID nennen, das führt zu einem Ducheiande. Benne sie nach der Tabelle: ID_Employee, dann kannst du auch die FK ohne Namensänderung so benennen. - Wenn du FK benennst, benenn sie immer nach dem gleichen Schema. id_employee ist der FK in die wt_employee. id_main sollte also id_time_main heißen etc. - type und andere reservierte namen solltest du vermeiden - Rechtschreibfehler sind ein Graus, aber in einem Datenmodell geht das gar nicht. Customer statt Costumer. - Gleiche Felder sollen gleich heißen: einmal remark und einmal remarks ist nicht gut. - Wenn Tabellen den gleichen Aufbau haben, sollte man immer überlegen, ob man das zusammenlegen kann: wt_time_type und wt_expenses_type - Die Tabellennamen sind entweder alle Einzahl (employee) oder alle Mehrzahl (expenses) - abhängige Tabellen sollten (für das Datenmodell) keinen eigenen PK brauchen (wt_time_main). Da hat es meist was mit dem Design. - Die wt_time_main passt so nicht. Was identifiziert die Tabelle? Kunde+Angestellter+Tag? Ich würde die wt_time_main + Sub zusammenlegen. Das entspricht ja auch viel mehr der Wirklichkeit. Ein MA ist bei Kunde X von/bis und macht was. |
AW: Sinnvoller aufbau einer DB
Zitat:
|
AW: Sinnvoller aufbau einer DB
:shock:
Naja, das würde ich schon eher vermeiden. Tabellen, die nichts miteinander zu tun haben, sollten nicht in einer DB liegen. Alternativ gibt es noch die Möglichkeit, das mit Schemas zu lösen. Aber wie gesagt, wenn alle gleich heißen, kann man´s weglassen. Wenn NICHT alle gleich heißen, dann nicht. Ich dachte, das erschließt sich von selbst. |
AW: Sinnvoller aufbau einer DB
Zitat:
|
AW: Sinnvoller aufbau einer DB
Vielen Dank für diese äußerst konstruktive Kritik.
Werde mich bemühen alles zu beherzigen. Zitat:
Zitat:
Aus dem Begriff Kunde sollte besser Projekt werden. Da es beim gleichen Kunde mehrer Projekte geben kann. In der wt_time_sub gibt es mehrere Einträge die sich auf den gleichen Tag, den gleichen MA und das gleiche Projekt beziehen. Daher nur der Verweis auf die wt_time_main (ist auch ein ungünstiger Name für diese Tabelle.) Ich bin da Gedanklich wahrscheinlich schon wieder zu weit... Ich hatte ja geschrieben das ich erstmal nur den monatlichen Stundenreport umsetzen will, aber habe schon die Serviceberichte mit im Hinterkopf. Da muss ich mir jetzt nochmal Gedanken machen ob ich das alles zusammenpacke oder ob ich hier eher getrennte Bereiche machen will. Wahrscheinlich deutlich einfacher und weniger komplex, aber dafür in gewissen Bereichen Redundant... :freak: |
AW: Sinnvoller aufbau einer DB
Zitat:
Weiterhin besteht dann die Möglichkeit über Zeiträume Abfragen zu gestalten. "Was haben wir am 31.02.2056 gemacht?" Gruß K-H |
AW: Sinnvoller aufbau einer DB
Hallo,
ich handhabe das so: Ein PK hat erst mal nichts mit den Daten der Tabelle zu tun, erst ist also ein artificial key (künstlicher Schlüssel). Dass kann ein Integer (AutoInc) oder eine GUID sein. Vorteil: Der Kunde sagt: "Das Feld kann nie und nimmer doppelte Werte haben", z.B. Rechnungsnummer -> mein PK Der Kunde sagt 2 Jahre später "Die Rechnungsnummer kann jetzt doppelt sein, weil die Standortnummer zusätzlich dazukommt. Wir nennen das jetzt zusammengesetzte Rechnungsnummer." Merke: Glaube keinen Kunden ;) |
AW: Sinnvoller aufbau einer DB
In den meisten Wawi ist die Rechnungsnummer ein Freitextfeld. Dieses wird z.B. über Generatoren und/oder Trigger bei neuen Belegen befüllt. Viele Firmen führen in ihren Rechnungsnummern z.B. auch das Geschäftsjahr. Daher sollte man hier nicht auf die Idee kommen und die Rechnungsnummer durch Schlüsselverkettungen aus verschiedenen Tabellen zu verketten. Denn sobald mal jemand auf die Idee kommt, den Nummernkreis zu ändern ohne das Geschäftsjahr mit zu ändern, hat man genau den Fall der doppelten Belegnummern.
Vielmehr sollte man die in einer Belegtabelle als Freitextfeld anlegen. Auf dieses Feld dann einen Unique-Constraint zu legen kann aber sinnvoll sein. Muss man dann aber auch entsprechend abfangen um im Realbetrieb genau die Fälle abzudecken wo der Anwender Mist baut. |
AW: Sinnvoller aufbau einer DB
Hallo,
das mit der Rechnungsnummer war nur ein konstruiertes Beispiel. Mir ging es hier eher darum, dass man als PK wirklich einen künstlichen Schlüssel nimmt, der mit den eigentlichen Daten nichts zu tun hat. Sollte ein "richtiges" Feld eindeutig sein müssen, bekommt man das auf DB-Seite locker über einen zusätzlichen Unique-Index hin. |
AW: Sinnvoller aufbau einer DB
Zitat:
|
AW: Sinnvoller aufbau einer DB
Zitat:
Gruß K-H P.S. Das gilt auch für die Einsparug des PK in einigen Tabellen. |
AW: Sinnvoller aufbau einer DB
Hallo,
Zitat:
"Das war mein Vorgänger." "Das machen wir immer so." :) Zitat:
Platzprobleme auf der Festplatte Connor 170 MB? |
AW: Sinnvoller aufbau einer DB
Zitat:
Connor kenne ich auch noch. Ich weiß noch, wie ich zig 3,5" Disketten in der Hand hatte um Novel Netware auf einem 486 mit 'ner Connor zu installieren... |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 06:35 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz