mysql: Redundanzen vermeiden oder nicht?

[Pit]

Hallo Forum,

es geht um diese Designfrage. Terminkalender z.b für mehrere User eines Teams. User1, User2 und User3 sollen an 4 aufeinanderfolgenden Tagen einen Termin wahrnehmen. Der Termin wird eingetragen.

Bisher war die DB-Organisation so, dass es eine Tabelle Termine gibt, in der alle wesentlichen Daten, wie Anfang, Ende, Terminort, Terminbeschreibung, usw. enthalten sind. Zudem eine 2. Tabelle, in der UserID sowie TerminID enthalten sind. Weiterhin einige andere Tabellen, die für meine Fragestellung zunächst aber nicht relevant sind.

Denn nun hat User 2 an Tag2 einen Arzttermin und kann erst später teilnehmen und User 3 fällt an Tag 3 komplett aus und diese Änderung soll eingetragen werden.

Mir fallen derzeit nur 2 Lösungen ein, diese Terminänderung DBseitig zu organisieren:

1. Start und Ende des Termins in eine weitere Tabelle oder gleich in die Teilnehmertabelle outsourcen oder
2. Die Maximallösung, nämlich 1 Tabelle mit User x Tagen Termineinträgen, die allesamt einzeln editiert werden können.

Ganz schön redundant, die 2. Lösung, nicht wahr?

Könnt Ihr mir mal Eure Gedanken zu dem Problem und/oder den beiden Lösungen sagen?

Pit

[Rolf B]

Hallo Pit,

du musst bedenken, dass die Attribute "Beginn" und "Ende" am Termin eine andere Semantik haben als an der "UserTermin" Beziehungstabelle.

Am Termin beschreiben sie den Termin.

In UserTermin beschreiben sie, in welchem Zeitraum der User am Termin teilnimmt. Das kleine Detail, dass ein Usertermin-Zeitraum nicht außerhalb eines Termin-Zeitraums liegen darf, kannst Du nicht gut in der DB modellieren.

Normalerweise speichert eine Termin-DB nur den Zeitraum eines Termins. Wer nicht teilnimmt, sagt ab (das ist der "Zusage-Status", der in UserTermin zu finden sein sollte). Wenn Du für die Termine-Sicht des Users X ermöglichen willst, dass er seine abweichende Teilnahmedauer angezeigt bekommt, brauchst Du Beginn und Ende an beiden Tabellen. In UserTermin sollten sie nullable sein, dann greift defaultmäßig der Zeitraum am Termin.

Rolf

[Pit]

Hallo Rolf,

ich nachvollziehe, was Du schreibst. Wäre es aber nicht denkbar, dass "zeitraumlose Termine" existieren, an denen User zeitraumgebunden teilnehmen?

Beispiel: Fortwährend werden Mietwagen vermietet und an diesem Wochenende miete ich mit von Fr-So einen davon. Oder: Täglich praktiziert meine Arzt und gestern war ich von 10-12 Uhr dort. Wo ist der Vorteil, den Terminzeitraum in die Termintabelle zu nehmen und beim User zu NULLen?

Pit

[Rolf B]

Hallo Pit,

"Zeitraumlose Termine" sind wohl eher Öffnungszeiten. Die trägt sich aber niemand in seinen Kalender ein, oder?

Dass ein User an einem Termin über die volle Strecke teilnimmt, wäre für mich die Normalsituation. In dem Fall setze ich die spezifischen Beginn/Ende-Felder für ihn auf NULL. Hat er einen spezifischen Teilnahmezeitraum, wird der eingetragen. Aus Sicht eines ER-Modells könnte man sich das vorstellen als eine m:n-Beziehungsklasse "UserTermin" mit einer Subklasse "UserTerminAbweichend" - oder so - die beide auf die gleiche DB-Tabelle gemappt werden.

Der Termin hat Beginn und Ende - das ist der Rahmenzeitraum. Bei einer mehrtägigen Konferenz wäre es vielleicht auch sinnvoll, mehrere Termine einzutragen - es ist oft so, dass da die Zeitfenster pro Tag unterschiedlich sind. Und jeder Teilnehmer kann während des vollen Zeitraums teilnehmen, dann hat er NULL in den UserTermin-Feldern stehen, oder in einem eigenen Zeitraum. Die Application prüft, dass der eigene Zeitraum innerhalb des Rahmenzeitraums liegt, und meldet bei Änderungen des Rahmenzeitraums ggf. an die User, dass der eigene Zeitraum auf einmal nicht mehr passt.

Beginn und Ende am Termin ganz wegzulassen und nur am User zu speichern, halte ich nicht für zielführend. Dann hast Du (a) Redundanzen und (b) keine Möglichkeit, den Rahmenzeitraum des Termins zu speichern. Du brauchst meiner Meinung nach beides. Es ist ja kein individueller Terminkalender, von dem wir hier reden, sondern ein Terminplanungssytem für mehrere Leute, deren Termine miteinander vernetzt sein sollen.

Rolf

[Pit]

Hallo Rolf,

Hm... stell Dir vor, Du hast einen Rahmentermin und ein User entscheidet, bereits einen Tag früher dort zu sein. Würde gem. Deinem Post als Fehler (oder wenigstens als warnung) gewertet.

Zudem: Wenn ich mir vorstellen, dass ich an einer Konferenz teilnehme, dann notiere ich auch nur Datum plus Uhrzeit meiner Teilnahme und nicht, von wann bis wann die Konferenz stattfindet. Stell Dir ein Selhtml Usertreffen vor, das 3 Tage stattfindet und ich habe vor, an einem hiervon teilzunehmen. Dann notiere ich in meinen Kalender diesen Tag und maximal in die Terminbeschreibung/-bemerkung, von wann bin wann das Usertreffen selber stattfindet. Ich köme nie auf die Idee, erst einen Gesamtzeitraum für das Usertreffen und anschließend den Tag meines Besuchs einzutragen.

Pit

[Rolf B]

Hallo Pit,

irgendwie habe ich den Eindruck, dass Du zwischen den Userstories deines Terminsystems hin und herpendelst. Um ein Feature zu designen, sollte man den Überblick über die Stories haben, dann aber Story für Story überlegen, was man dafür braucht.

Die Story, von der ich in diesem Thread ausgegangen bin, lautet so: Jemand erfasst einen Termin im System und ordnet mehrere Teilnehmer zu (Einladung, Dienstverpflichtung, wasauchimmer). Diese Teilnehmer werden zunächst als Vollzeit-Teilnehmer registriert, können dann aber ihre Teilnahmezeiten ändern. Diese Änderungen sollen für den Terminerfasser, vielleicht auch den anderen Teilnehmern, sichtbar sein. Durch die Zeitänderungen der Teilnehmer ist es möglich, dass es für sie mehrere Teilnahmeintervalle gibt.

Dass Du für Dich einen Termin einträgst, an dem kein anderer Nutzer dieses Termins teilnimmt, ist eine andere Story. Natürlich sollte das Datenmodell beide Stories bedienen können.

Wieder andere Storys könnten sein, dass User nachträglich eingeladen werden oder sich eigenständig an einen bestehenden Termin anhängen können.

Der konkrete Ablauf der Teilnahmezeitänderung muss auch noch betrachtet werden, das ist wieder eine andere Story.

So. Und nun bringst Du noch die Idee der vorzeitigen Anreise ins Spiel. In meinem Vorschlag wäre das keine Warnung, sondern würde von der Plausibilitätsprüfung abgelehnt. Denn damit wechselst Du vom gemeinsamen Termin zum Einzelschicksal und das gehört da nicht hinein; es sei denn, es erfolgt eine GEMEINSAME vorzeitige Anreise. Die wäre dann Teil des Terminzeitraums, dann trifft man sich ja auch irgendwo - und irgendwer kann das dann absagen weil er eigenständig anreist.

Wenn die vorzeitige Anreise individuell erfolgt, sehe ich das nicht als Teil des gemeinsamen Termins, die kann jeder für sich terminieren. Möglicherweise kann das Terminsystem vorsehen, dass man einen Termin als "abhängig von" einem anderen Termin einträgt - die Anreise wäre dann abhängig von der Tagung. Aber auch das ist eine andere Story. Du könntest es auch so machen, dass sich jeder User sich zu seiner Terminteilnahme Zusatzzeiträume eintragen kann (für Anreise, psychologische Einstimmung, nachträgliches Abdampfen, etc). Solltest Du aber nicht tun. Wer für einen gemeinsamen Termin Zusatzzeiten braucht, kann sich dafür einen eigenen Termin eintragen. Je mehr Komplexität, desto mehr Lernaufwand, desto mehr Testaufwand. KISS!

Ich habe fertig...
Rolf

[Pit]

Hi Rolf,

oh, für mich war das alles eine Story... 😉

Die Story, von der ich in diesem Thread ausgegangen bin, lautet so: Jemand erfasst einen Termin im System und ordnet mehrere Teilnehmer zu (Einladung, Dienstverpflichtung, wasauchimmer). Diese Teilnehmer werden zunächst als Vollzeit-Teilnehmer registriert, können dann aber ihre Teilnahmezeiten ändern. Diese Änderungen sollen für den Terminerfasser, vielleicht auch den anderen Teilnehmern, sichtbar sein.

Korrekt. Wobei halt diese Termine nicht ganz so in Stein gemeißelt sind, wie eine Dienstreise, eine Schulung oder eine Konferenz. In den Terminen ist immer auch ein bißchen "Flow". So eine Art "atmender Rahmen", wenn Dir das was sagt 😉

Durch die Zeitänderungen der Teilnehmer ist es möglich, dass es für sie mehrere Teilnahmeintervalle gibt.

Ich glaube, genau das ist noch ein(er der) Knackpunkt(e) bei meinem Design.

Dass Du für Dich einen Termin einträgst, an dem kein anderer Nutzer dieses Termins teilnimmt, ist eine andere Story. Natürlich sollte das Datenmodell beide Stories bedienen können.

Für mich genau dieselbe Story. Termin = Rahmen, Teilnehmer bin ich selber.

Wieder andere Storys könnten sein, dass User nachträglich eingeladen werden oder sich eigenständig an einen bestehenden Termin anhängen können.

Unbedingt. Ein Termin kann ausfallen, ein Mitarbeiter kann bei einem Termin durch einen anderen ersetzt erden.

Der konkrete Ablauf der Teilnahmezeitänderung muss auch noch betrachtet werden, das ist wieder eine andere Story.

Und wieder genau einer meiner Knackpunkte, siehe...

So. Und nun bringst Du noch die Idee der vorzeitigen Anreise ins Spiel [.... ]

Wenn die vorzeitige Anreise individuell erfolgt, sehe ich das nicht als Teil des gemeinsamen Termins, die kann jeder für sich terminieren.

Einverstanden.

Möglicherweise kann das Terminsystem vorsehen, dass man einen Termin als "abhängig von" einem anderen Termin einträgt - die Anreise wäre dann abhängig von der Tagung. Aber auch das ist eine andere Story. Du könntest es auch so machen, dass sich jeder User sich zu seiner Terminteilnahme Zusatzzeiträume eintragen kann (für Anreise, psychologische Einstimmung, nachträgliches Abdampfen, etc). Solltest Du aber nicht tun.

Ich werde mich hüten...

KISS!

Ich habe fertig...

Habe ich gelesen...Und von mir einen Dank für Deine Mühe!

Pit

[Rolf B]

Hallo Pit,

Ich habe fertig... Habe ich gelesen...Und von mir einen Dank für Deine Mühe!

Sorry, das sollte nicht heißen dass ich jetzt nichts mehr mit dem Thema zu tun haben will. War wohl das falsche Schlusswort zum Beitrag.

Rolf

[Pit]

Hallo Rolf,

Sorry, das sollte nicht heißen dass ich jetzt nichts mehr mit dem Thema zu tun haben will. War wohl das falsche Schlusswort zum Beitrag.

Nein, das kam gar nicht so bei mir an. Es kam eher so an, dass Du mal tief ausgeatmet hast, nachdem Du einen guten und langen Gedanken im Kopf längst fertig hattest und ihn dann verständlich formuliert und formatiert "aufs Papier" bringen mußtest. Das hat gut geklappt und Du hast Dir dabei viel Mühe gegeben. Und dafür habe ich mich (auch mal zwischendurch, wohlwissend, dass Du Dich damit nicht aus dem Thema verabschiedest) bedankt.

Pit

[Pit]

Hallo Rolf,

Edit: Ich sehe gerade, wie haben gleichzeitig geschrieben... Insofern kenne/kannte ich Dein vor wenigen Minuten abgesendetes Post noch nicht, während ich das schrieb... ich geh mal lesen 😉

Dass ein User an einem Termin über die volle Strecke teilnimmt, wäre für mich die Normalsituation. In dem Fall setze ich die spezifischen Beginn/Ende-Felder für ihn auf NULL. Hat er einen spezifischen Teilnahmezeitraum, wird der eingetragen. Aus Sicht eines ER-Modells könnte man sich das vorstellen als eine m:n-Beziehungsklasse "UserTermin" mit einer Subklasse "UserTerminAbweichend" - oder so - die beide auf die gleiche DB-Tabelle gemappt werden.

Ich habe Dein Modell übernommen. Du hast recht, es vermeidet Redundanzen und durch ausNULLen der Start/End Spalte in der Teilnehmertabelle läßt es sich noch komfortabel abfragen.

1. Irgendwie habe ich das Gefühl, dass ich hier als Entwickler einen Zielkonflikt verhindern muß. Entweder wird der Termin selber editiert. (In den allgemeinen Termindaten oder in Start/Endzeit.) Aber dann sollte keine Teilnehmer herausnehmbar oder hinzufügbar sein, der den Termin nicht zu 100% wahrnimmt. Oder es wird für einen (oder mehrere) User dieser Termin editiert, dann aber ausschließlich in Bezug auf Start/Endzeit (Edit: von mir aus auch innerhalb des allgemeinen Terminrahmens), nicht aber hierin und zudem in den allgemeinen Termindaten.

2. Ich hadere ein bischen mit Fall 2, und zwar damit, wie ich eintragen soll, wenn ein User an einem Tag der 4-tägigen Konferenz nicht oder erst später teilnimmt. Zerhacke ich dann seine Teilnehmedaten (1 Eintrag in der Teilnehmertabelle) in tägliche Teildaten (4 Einträge in der Teilnehmertabelle) oder wie gehe ich das an? Zudem ist dieser User dann komplett aus dem Gruppentermin raus oder nur für diesen Tag?

Pit

[Rolf B]

Hallo Pit,

den Fall, dass der Termin anderswohin verlegt wird, kannst Du nicht umgehen, that's life. Eine Terminverlegung sollte dazu führen, dass alle Teilnehmer auf "unbestätigt" gesetzt werden und ihre Einladung neu bestätigen müssen. Bei der Gelegenheit können sie dann auch ihre Nichtverfügbarkeiten updaten. Eine Mailbenachrichtigung für Einladungen/Terminänderungen/Absagen hast Du vorgesehen?

Zusagen stornieren musst Du auch für diejenigen, die vorher eine 100% Teilnahme hatten, denn die Verschiebung kann ja dazu führen, dass sie etwas absagen müssen. Wenn sich nur der Termininhalt ändert, aber der Zeitraum gleich bleibt, kannst Du die Zusagen stehen lassen. Sollte sich der Termin so gravierend ändern, dass die Zusagen wertlos werden, sollte er formal abgesagt und neu eingestellt werden. Das überlässt Du besser dem Organisator.

Sicherlich kann man aufwändige Logiken planen, wie man die bestätigten Zusagen zumindest teilweise übertragen kann. Ich würde aber vermuten, dass das beliebig kompliziert werden kann.

D.h. der Organisator muss Beginn/Ende am Termin ändern können, egal was die Leute in ihren Terminteilnahmen stehen haben. Die Teilnehmer können ihre Teilnahmezeiträume ändern, aber nur im Rahmen des Zeitraums, den der Organisator gesetzt hat. Der Organisator hat Priorität. Denke ich mal so.

Rolf

[Pit]

Hallo Rolf,

Sicherlich kann man aufwändige Logiken planen, wie man die bestätigten Zusagen zumindest teilweise übertragen kann. Ich würde aber vermuten, dass das beliebig kompliziert werden kann.

Jetzt reden wir gerade aneinander vorbei. Im ersten Launch soll dieser Terminplaner, der ausschließlich für Teams gedacht ist, die sich eh täglich sehen und eine Teilnehmerzahl von 10 seltenst überschreiten werden, gedacht sein. Da brauchen Termine nicht gegenseitig bestätigt und/oder storniert werden. Das wäre komplett overdressed. Die sprechen sich ab und tragen das ein. Das Einzige, was eben passieren kann, ist, dass jemand für einen Termin ausfällt oder etwas früher oder später erst erscheint. Vielleicht will mal wer an einen Termin erinnertw erden, das ist tatsächlich eingeplant. Aber dazu habe ich keine Fragen.

Ich denke, ich weiß jetzt, wie ich morgen weiter vorgehen werde. Ich werde dem User die Möglichkeit geben, den Termin auf 2 (oder mehr) Arten zu editieren. Einzeltermin, Gruppentermin, o.ä. und zur entsprechenden Editiermöglichkeit verschiedene Optionen freischalten, die hier editiert werden können. Sollte aus einem Gruppentermin ein Einzeledit erfolgen, ist dieser User für diesen Tag nicht mehr im Gruppentermin. Gruppenedits ändern immer den Termin für alle.

Das Einzige, was ich noch nicht genau weiß, ist (Fall 2, s.o.), wie ich eintragen soll, wenn ein User an einem Tag der 4-tägigen Konferenz nicht oder erst später teilnimmt. Zerhacke ich dann seine Teilnehmedaten (1 Eintrag in der Teilnehmertabelle) in tägliche Teildaten (4 Einträge in der Teilnehmertabelle). Alternativ könnte ich daraus ja auch:

• 3 Einträge machen (1 x 2 Tage und 2 x 1 Tag)
• 1 Negativeintrag für diesen Edittag vornehmen plus einen neuen Positiveintrag (wobei ich keinen Schimmer habe, wie aus einem 4-tägigen Termin ein Negativtermin "subtrahiert" werden könnte.

Pit