Pit: mysql: Redundanzen vermeiden oder nicht?

Beitrag lesen

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