Alex: MySQL Performance bei großen Tabellen (viele Felder leer)

Beitrag lesen

HAllo Ilja,

vielen Dank für deine Antwort erstmal.
Ich mache sicher 100 Denkfehler im Daten-Design und habe da auch noch viel vor mir aber das was du ansprichst ist schon absicht.
Also wenn jetzt die Vorlage geändert wird, dann sollen auch die Kalendereinträge geändert werden, außer sie wurden vorher schon angepasst. Von daher würde das schon passen mit der VorlageId.

Ob diese Absicht jedoch so gut ist das muss ich noch weiter überdenken.
-ist irgendwie kompliziert. Man soll einigermaßen einfach änderungen machen können und dabei auch gleich alle Kalendereinträge ändern können wenn man sich in der Vorlage geirrt hat zum Beispiel. Aber es soll auch sicher sein, dass Kalendereinträge, wo schon jemand gebucht hat (ist ein Online Buchungssystem) nicht geändert werden dürfen.
Dann soll es auch noch Serienelemente (wie Outlook) geben, bei denen soll man entweder die ganze Serie auf einmal anpassen können oder nur ein Teil (der fliegt dann so halb aus der Serie raus würde aber z.b. beim Löschen der Serie trotzdm gelöscht werden können...

Vielleicht mache ich es ja so:
In der "Kalender" Tabelle wird alles aus der Vorlage rausgespeichert + die Vorlage ID.
Jetzt steht es dann aber doppelt da, was man ja eigentlich vermeiden will..naja.
Wenn die Vorlage geändert wird gibt es eine Option ob man auch schon erstellte aber noch nicht gebuchte Kalendereinträge die in der Zukunft liegen ändern möchte. Dann wird jedes Kalenderelement mit der entsprechenen Vorlage ID angepasst.
Wenn man jetzt nachträglich ein Kalenderelement/Serie ändert, dann wird die Vorlage ID gelöscht /bzw. irgendwie Codiert, so dass diese Änderungen nicht bei einer änderung der Vorlage überschrieben werden.

...Klingt ganz OK oder? Weil anderst müsste ich ja das was schon gebucht wurde oder geändert wurde erst Archivieren und dann die Vorlage ändern...hm

gruß
Alex