nicht angemeldet
MySQL Performance bei großen Tabellen (viele Felder leer)
Hallo Leute,
ich bin grad dabei ein etwas größeres Projekt zu bauen, weshalb ich mich auch mal mit der Performance beschäftigen sollte.
Der Sachverhalt.
Ich habe eine Tabelle mit meinen "Vorlagen", diese Vorlagen können dann über einen Kalender auf bestimmte Termine gebucht werden.
Das geschieht so, dass der Admin einfache ine Vorlage aussucht und passende Terminde dazu speichert.
Dies wird dann in eine Tabelle "Kalender" gespeichert. Also da kommt rein: ID der Vorlage und die entsprechenden Daten.
Jetzt zum eigentlichen Problem.
Man soll auf wunsch auch jede Vorlage beim einbuchen etwas verändern können. Also z.B. änderung des Preises, weil gerade Hauptsaison ist...
Ich habe mir jetzt überlegt, die "Kalender" Tabelle so aufzubauen, das eben Datum und Vorlagen ID als Felder vorhanden sind, aber zusätzlich noch alle Felder die auch in der Tabelle "Vorlagen" sind. Wird eine Vorlage nicht geändert, so werden diese Felder einfach leer gelassen und nur die ID eingetragen, wird die Vorlage in einem Punkt geändert, so wird keine Vorlagen ID eingetragen sondern alle anderen Felder.
Also ich habe dann eine Tabelle mit 5 mal so vielen Feldern wie ich sie im Normalfall bräuchte und normalerweise werden diese vielen Felder leergelassen.
Hoffe ihr versteht wie ich das meine...
Meine Frage jetzt: Ist es so der performanteste Weg oder sollte ich die einmaligen Vorlage änderungen lieber ausgliedern und bei Vorlage ID im falle einer abweichung z.b. abweichung_ID eintragen um so an die Daten zu kommen?
Jetzt hab ich so viel geschrieben - hoffe es lohnt sich und jemand versteht was ich meine ;)
Ich wäre übrigens auch über Tips dankbar, wo ich etwas über MySql und Performance lesen kann. Also eben etwas speziell für größere Projekte. Am liebsten wär mir ein gratis Ebook oder Online Tutorlial.
mit den besten Grüßen
Alex
-
yo,
Ich habe mir jetzt überlegt, die "Kalender" Tabelle so aufzubauen, das eben Datum und Vorlagen ID als Felder vorhanden sind, aber zusätzlich noch alle Felder die auch in der Tabelle "Vorlagen" sind. Wird eine Vorlage nicht geändert, so werden diese Felder einfach leer gelassen und nur die ID eingetragen, wird die Vorlage in einem Punkt geändert, so wird keine Vorlagen ID eingetragen sondern alle anderen Felder.
du gehst den falschen weg. erst einmal solltest du das datendesign für deine zwecke ordentlich designen. was du dort oben machen willst ist der falsche weg. einen gutes daten-design zu entfernen ist in vielen fällen recht schwierig, wo meiner meinung nach selbst viele fachbücherversagen.
es gibt unter anderen einen fehler, den viele machen, nämlich dinge die gleich aussehen, müssen nicht gleich sein. hört sich erst mal komisch an, aber dahinter steckt, dass man nach abhängigkeiten modelliert. und in diese beliebte falle bist du meiner meinung nach getreten. die einträge in den kalender haben keine abhängigkeiten zu den vorlagen. sprich du solltest "immer" die werte in der kalender tabelle speichern und "nie" die werte aus der vorlage. ich würde die vorlagen_id ganz rausnehmen, vielleicht höchtens drinne lassen, um zu wissen, welche vorlage er für die einträge nun benutzt hat. aber letztlich ist es egal. es zählen die werte im kalender.
als beispiel der unabhängigkeit: wenn du später mal in den vorlagen werte ändern willst, dann sollte sich ja nicht die werte in den kalendern ändern. das können ja durchaus auch kalendereinträge sien, die in der vergangenheit liegen. das würde sie aber tun, wenn du über den fremdschlüssel die werte ausliesst. sicherlich könnte man jetzt einen workaround ausdenken, indem man verbietet, eine vorlage jemals zu verändern. aber das ist der falsche weg.
und was die performance-problematik angeht, erst mal anaylisieren, ob es den überhaupt engpässe gibt, bevor man reagiert.
Ilja
-
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-
yo,
Also wenn jetzt die Vorlage geändert wird, dann sollen auch die Kalendereinträge geändert werden, außer sie wurden vorher schon angepasst.
du sagst es ja selber, du willst nicht alle ändern. nur weil man mehrere datensätze auf die gleiche weise ändern will, dann heisst das noch lange nicht, dass sie abhängig voneinander sind. ausserdem willst du ja die vergangenen kalendertage nicht ändern.
ich kenne deine wiederzugegebene umgebung nicht genau. aber auf den ersten blick würde ich sagen, jeder tag hat seine eigenen werte, auch wenn verschiedene tage dabei durchaus die gleichen werte haben können. aber wie gesagt, was gleich aussieht, muss nicht gleich sein.
-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.
du verlierst dich in diesem gedanken, viele datensätze auf einmal ändern zu wollen. jeder kalendertag kann unabhängig von den anderen kalendertagen eigene werte besitzen. ob diese nun gleich sind oder nicht, das ist erst mal zweitranging. sollte man sich nun bei einer vorlage geirrt haben, dann kann man immer noch mit einem einzigen update befehl nur die daten ändern, die auch wirklich geändert werden sollen.
vielleicht hilft es dir, anders herum an die sache heran zu gehen. nehmen wir an, einige kalendertage haben die gleiche vorlage benutzt und es liegt noch keine änderung oder buchung vor und alle termine liegen in der zukunft. nun willst du aber an einem kalendertag die werte ändern. dann kannst du auch nicht einfach die vorlage ändern, weil sich sonst alle anderen mitändern würden. nun kannst du natürlich sagen, dem eine neue vorlage zuzuordnen, aber das löst das problem nicht, es verschiebt es nur.
Vielleicht mache ich es ja so:
In der "Kalender" Tabelle wird alles aus der Vorlage rausgespeichert + die Vorlage ID.das wäre schon eher eine option.
Jetzt steht es dann aber doppelt da, was man ja eigentlich vermeiden will..naja.
das ist leider ein weit verbreiter irrtum. normaliserung entfernt keine redundanzen. doppelte werte sind grundsätzlich nicht verkehrtes. es ist eine frage der kontrolle.
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.
kann man so machen, aber ist mit vorsicht zu genießen.
Ilja
-
Hey Ilja,
noch mal vielen Dank für deine kompetente Antwort.
Ich glaube ich wei jetzt wie ich das Ganze(fast) angehe. Du scheinst dich sehr gut mit Dantenbanken auszukennen? Machst du das professionell?
Vielleicht hast du dann auch den einen oder andern Link der für mich interessant sein könnte.Jetzt mache ich mir nur noch gedanken über meine Serienelemente.
Habe mir erst gedacht, dass es ja nur so gehen kann, dass ich speichere, dass es eine Serie werden soll und dann einfach im Kalender an jedem Tag diese Serie anzeige. Einzelne DB Einträge gehen ja nicht weil man ja "unendlich" in die Zukunft geht.JEtzt denke ich mir: Wenn ich einen Geburtstagskalender oder so mache OK dann macht mans so, aber wer bitteschön bucht etwas 10 Jahre im Voraus. Also bin ich zu dem Schluss gekommen. Es muss immer ein Anfangs und ein Enddatum gegeben werden und es werden dann eben X DB einsträge generiert. Die bekommen eine SerienID, dass man sie auch zusammen Löschen und ändern kann und gut is. Dann ist es auch gleich mit den Buchungen eindeutiger und so weil man eben eine Buchungs ID hat, die genau dem Tag entspricht....
gruß
Alex
-
-
-