Sinnvoller aufbau einer DB

[mkinzler]

Test

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

[jobo]

Zitat von Beach:

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" ?¿?

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

[TigerLilly]

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.

[Beach]

Vielen Dank für diese äußerst konstruktive Kritik.
Werde mich bemühen alles zu beherzigen.

Zitat von TigerLilly:

[...]
- abhängige Tabellen sollten (für das Datenmodell) keinen eigenen PK brauchen (wt_time_main). Da hat es meist was mit dem Design.

Kannst du mir das bitte etwas näher ausführen? Ich bin leider nicht mehr so Fit in dem ganzen Thema wie ich anfangs noch geglaubt habe und habe hier doch einiges an Lernbedarf. Daher interessiert es mich sehr, was du hiermit meinst.

Zitat:

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

Das wirbelt meine Gedanken gerade wieder frisch durcheinander.

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

[TigerLilly]

Zitat von Beach:

Zitat von TigerLilly:

[...]
- abhängige Tabellen sollten (für das Datenmodell) keinen eigenen PK brauchen (wt_time_main). Da hat es meist was mit dem Design.

Kannst du mir das bitte etwas näher ausführen?

Meine Erfahrung:
In der Designphase (konzeptionelles Datenmodell) sollte die DB so sauber wie möglich designt werden. Dh auch, dass ich je Tabelle ein oder mehrere Attribute als PK identifizieren kann. Wenn nicht, ist das immer ein Alarmzeichen, weil ich die Identität eines Datensatzes willkürlich (sonst hätte ich ja einen PK) durch Businesslogik (abzählen) herstelle. Das ist nur sehr selten zulässig. Meist verschleiert eine ID, dass ich nicht weiß, was die Tabelle identifiziert.

Für das physische Datenmodell (wo ich uU auch technische Beschränkungen habe) kann eine bedeutungslose ID natürlich sehr sinnvoll sein.

Zitat:

Das wirbelt meine Gedanken gerade wieder frisch durcheinander.
…
(ist auch ein ungünstiger Name für diese Tabelle.)
...
Ich bin da Gedanklich wahrscheinlich schon wieder zu weit...
...
Wahrscheinlich deutlich einfacher und weniger komplex, aber dafür in gewissen Bereichen Redundant...

Klingt nach nochmal nachdenken + besser Bezeichnungen wählen. :- )

Aber: Redundant ist böse.

[p80286]

Zitat von TigerLilly:

- abhängige Tabellen sollten (für das Datenmodell) keinen eigenen PK brauchen (wt_time_main)...
- 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.

Da bin ich ganz anderer Meinung. Durch den PK hast Du einen eindeutigen Schlüssel für einen Zeitraum, das kann sinnvoll sein wenn der Zeitraum sich primär auf ein Projekt, Reparatur, Maschine etc. bezieht und nicht nur auf MA.

Weiterhin besteht dann die Möglichkeit über Zeiträume Abfragen zu gestalten. "Was haben wir am 31.02.2056 gemacht?"

Gruß
K-H