Sinnvoller aufbau einer DB

[jobo]

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...

[mkinzler]

Test

[p80286]

Zitat:

Zitat von Beach (Beitrag 1428846)

es können mehrere Einträge pro Tag und Person sein

id

Pers_id

type_id

starttime

endtime

comment

Problematisch könnten Fehleingaben mit Zeitüberschneidung werden.

Gruß
K-H

[Beach]

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.

[stifflersmom]

Zitat:

Zitat von jobo (Beitrag 1428842)

Zitat:

Zitat von stifflersmom (Beitrag 1428838)

.. damit in Summe keine stundenzahl von über 24 für einen Tage ermittelt werden kann

Kommt in der Praxis wahrscheinlich selten vor oder?
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.

Wie oft kann ich Dir nicht sagen, aber wenn Du z.B. Dir die Bereitschafts-/Arbeitszeiten von Ärzten im Krankenhaus ansiehst, wirst Du feststellen, dass es durchaus vorkommen kann bzw. vorkommt.

[jobo]

Zitat:

Zitat von Beach (Beitrag 1428891)

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.

Also noch mal ganz pragmatisch:
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?

[Beach]

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.

[TigerLilly]

- 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.

[stifflersmom]

Zitat:

Zitat von TigerLilly (Beitrag 1428983)

- 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 mehr als eine Datenbank zur Verfügung steht, gebe ich Dir recht. Hast Du nur Eine, macht es durchaus Sinn so zu arbeiten.

[TigerLilly]

: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.