Hallo allerseits

Leider habe ich keine Erfahrung damit, wie es sich von der Performance her verhält, wenn ich bei großen Tabellen (d.h. viele Datensätze) Spalten hinzufüge oder lösche.

Es handelt sich dabei um eine mySQL-DB.

Für ein CMS, welches ich in meiner Freizeit entwickle habe ich vorgesehen, dass man quasi nach Belieben Tabellen anlegen und auch die Spalten selbst bestimmen kann.
Jedoch habe ich mir nie Gedanken über die Performance gemacht, wenn man u.U. viele Spalten hin und her erstellt/löscht.

Falls da jmd. von euch Erfahrung mit hat, würde ich mich über Feedback freuen.

Die Alternative, die ich hätte wäre eine komplett dynamische Struktur, also eine Tabelle mit den Feld-Definitionen und eine mit den Inhalten (Datensatz-ID, Feld-ID, Inhalt). Dann bräuchte man an der Tabellenstruktur nichts ändern, allerdings würde ich dann auf so Dinge, wie Indizierung von bestimmten Spalten verzichten müssen.

Ich denke nicht, dass es sinnvoll ist, das Datenbankschema nach dem Erstellen groß zu verändern. Besonders dann nicht wenn sich schon Daten darin befinden.

__________________
Markus Wulftange

Erstmal danke für Deine Antwort.

Ich denke schon, dass es sinnvoll sein kann, z.B. kann ich ein Modul schreiben, welches z.B. 1 Tabelle, um irgendwelche Daten zu speichern. Wenn ich dieses Modul irgendwo einsetze, dann kann es sein, dass je nach Einsatzzweck evtl. das eine oder andere Feld mehr nötig wird.
Natürlich tritt der Fall nicht allzu häufig auf, aber im Idealfall soll ein User, der nicht wirklich viel oder gar gar keine Ahnung von dem ganzen hat sich ein Feld zusätzlich anlegen können, wenn er z.B. zusätzlich zu den Benutzern noch das Geburtsdatum oder sonstwas speichern möchte.

Gewisse Basis-Felder sind also fest und andere können je nach Einsatzgebiet noch dazu kommen. Das Problem, das ich dabei habe ist, dass man auch Felder anlegen kann, die auf andere Datensätze verweisen, wo also nur die ID als Referenz gespeichert wird.
Wenn man jetzt komplexere SQLs hat und viele Daten, dann ist es schön, wenn man auf diese Spalten einen Index draufsetzt, da der Performance-Unterschied doch enorm ist.

Wenn ich mit phpMyAdmin beispielsweise eine einigermaßen große Tabelle (> 100.000 Datensätze) ändere, dann geht das auch noch recht fix, so viel mehr werden es wohl erstmal bei nem CMS nicht werden.

Ich weiß aber nicht, was sich so im inneren abspielt, wenn man u.U. 100 mal ne Spalte anlegt, wieder löscht, wieder anlegt, teilweise nen Index auf die Spalten setzt, usw.
Ob die DB-Files evtl. irgendwann so geschrottet sind bzw. fragmentiert oder sonstwas, dass die Performance nachhaltig durch solche Aktionen beeinflusst wird.

Bei kleineren Tests konnte ich keine Probleme feststellen, aber ich weiß ja nicht.

Und eigentlich will ich die andere Variante nicht wirklich in Erwägung ziehen, da wie gesagt, zum einen die Indizes fehlen, zum anderen muss ich z.B. für Suchanfragen erstmal eine Abfrage für die Suche durchführen und dann eine, wo ich mir wirklich die kompletten Datensätze hole und zusammenbaue, was ich auch nicht so schön finde, da ich ja keine direkte Möglichkeit habe auf die Felder zuzugreifen.

Also ich sehe das wie Gumbo.
Das Tabellenlayout einer DB muss komplett mit dem Setup der Software stehen. Eventuelle Änderungen über ein Softwareupdate.

Aber einem User erlauben Spalten in einer Tabelle hinzuzufügen oder gar zu löschen sollte in jedem Fall verhindert werden. Wie willst du vor dem Löschen feststellen, ob die vorhandenen Datensätze nicht noch an einer anderen Stelle im System genutzt werden?

Wenn du dynamische Felder bei Datensätzen hast, solltest du lieber auch die Tabellenstruktur für diese Dynamik ausrichten.

Z.B. indem du das erforderliche Datensatzfelder dynamisch im System erstellst.
table_datensatz (ID, Name)
table_feld (ID, datensatz_ID, Position, Name)
table_feldinhalt(ID, feld_ID, Inhalt)

Jetzt kannst du dynamisch Felder ergänzen, ohne dein Tabellenlayout zu ändern.

Hoffe das ist halbwegs verständlich.

__________________
Gruß Chrunchy

"Eine Theorie ist eine Vermutung mit Hochschulbildung" (James Earl Carter)

Ja, ich weiß schon, was Du/Ihr mein(s)t.

Das Problem, dass ich dabei habe ist, dass ich alle, wirklich alle Datensätze dann so abbilden müsste, User, Gruppen etc. ebenfalls, da ich bisher die Datenbank-Struktur mit sich selbst abbilde, damit ich für's Backend alle Infos in der DB habe, die ich brauche.

Und wenn ich einen Datensatz holen will, der bestimmte Kriterien erfüllt, dann muss ich erstmal alle IDs holen, wo ich dann auf die Felder filtere, anschließend dann alle Daten zu den IDs, um dann die Datensätze zusammenzubauen, also nach dem Motto:
Anschließend dann in PHP das Ergebnis der letzten Abfrage zu einer regulären Liste zusammenbauen.

Stelle ich mir von der Performance schrecklich vor.

Andererseits fällt mir gerade ein, dass ich ja auch für jeden Datentyp, den ich unterscheiden möchte eine eigene Value-Spalte verwenden kann, so dass ich bei Referenzen dann doch wieder einen Index draufsetzen könnte.

Danke für eure Meinungen, ich hätte nicht gedacht, dass das so auf Ablehnung trifft, aber im Grunde habt ihr ja Recht.

Ich probier's einfach mal aus.

Mich macht stutzig dass dich deine eigene Aussage nicht selbst zum Grübeln bringt.Wenn jemand von einem System nichts versteht, sollte er dies auch nicht verändern können.

Biete so etwas lieber modular an. Von dem Benutzer eines CMS muss – um es wirklich aufs Wesentliche zu reduzieren – eigentlich nur die ID bekannt sein. Der Rest ist nur gestalterisches Beiwerk und kann als Modul angeboten werden.

__________________
Markus Wulftange

Naja, um es ein wenig zu erklären oder es zumindest zu versuchen :

Ich habe eine z.B. Tabelle Records, welche alle Datensätze enthält, eine Tabelle, damit jeder Datensatz einzig durch seine ID eindeutig identifiziert werden kann. Anhand dieser ID kann ich dann bestimmen, ob dieser Datensatz eine Tabelle, ein Feld oder irgendeinen Inhalt repräsentiert.
Gleichzeitig habe ich eine Tabelle, wo Platzhalter gespeichert werden, Platzhalter sind kleine Templates zur Anzeige von Feldern der Datensätze, welche auch zum Bearbeiten genutzt werden.
Das heißt, dass jedes Feld einer Tabelle mit einer eigenen ID in der DB gespeichert sein muss, damit ich dafür einen Platzhalter speichern kann.

Vom Ablauf her passiert folgendes:

1. getRecord wird mit einer ID aufgerufen
2. Datensatz wird aus der Records-Tabelle geholt
3. In der Records-Tabelle steht die ID der virtuellen Tabelle drin, wenn man so will
4. Die Felder der virtuellen Tabellen werden geholt (wegen evtl. Berechtigungen oder auch nicht)
5. Mit den Feldern, die zurückgeliefert werden, wird ein Query zusammengebaut, welches nur die Felder aus der virtuellen Tabelle selektiert, welche auch gelesen werden dürfen
6. Datensatz wird zurückgeliefert

Beim Bearbeiten eines Datensatzes werden zusätzlich noch die Platzhalter zu den Feldern geholt, geparst und anstelle der eigentlichen Inhalte in die Keys des Datensatzes gespeichert.
Problem hierbei ist, dass die Tabelle 'Records' selbst auch Felder enthält, welche per Platzhalter bearbeitbar sein sollen/müssen.

Das ganze ist irgendwie ganz schön quer, aber ich weiß nicht, wie ich es anders hinbekommen soll, dass ich nicht dazu gezwungen bin bestimmte Felder fest in die Templates zu schreiben, um sie zu bearbeiten, im Moment ist halt alles recht dynamisch gestaltet.
Ich will also nicht explizit ein input-Feld im Template stehen haben, wo ich einen Namen eingebe, ob es ein input-Feld oder eine Textarea ist, oder evtl. ein Dropdown oder was auch immer soll aus dem Platzhalter kommen.
Wenn ich nun ein neues Feld in einer Tabelle anlege, dann gebe ich für dieses Feld einen Platzhalter an und wer dieses Feld bearbeiten darf und bin fertig, ich muss mich um keine Templates kümmern oder sonstwas. Ich kann für alle Seiten, die im CMS verwaltet werden eigene Platzhalter angeben, so dass ich mit ein paar Klicks sofort ermögliche, dass das Feld bearbeitet werden kann und auf jeder Seite im eigenen Seitenstil. Ich hoffe das ist einigermaßen verständlich.

Auf die Art kann ich z.B. ein Gästebuch anlegen, ohne eine Zeile Quellcode schreiben zu müssen, außer evtl. ein wenig Template-Code.
Ich gebe für die Felder die Platzhalter für's Backend und für's Frontend an und bin fertig. Ich habe dadurch sofort eine Eingabemaske für's Frontend in dessen Layout und gleichzeitig für's Backend in diesem Layout.
Falls mehrere Front-/Backends existieren kann ich so auch den Datensatz in kürzester Zeit auf allen Oberflächen anzeigen/bearbeiten.

Ich habe gerade mal versucht nur mit einer Records- und einer Datentabelle das ganze irgendwie aufzubauen, aber das wird nix.
Dann werde ich wohl doch bei meiner alten unkonventionellen Art bleiben.

Aber Danke, das hat mich wenigstens nochmal grundsätzlich darüber nachdenken lassen.

Kleiner Nachtrag (Sorry wg. Doppelpost):

Ich habe gerade noch kurz was überflogen, und die Performance bei sehr großen Tabellen ist wohl wirklich totaler Müll, wenn man z.B. einen Index entfernt oder den Default-Wert ändert.

Ich lasse es erstmal beim alten, so dass die Möglichkeit grundsätzlich besteht die Tabelle selbst zu ändern, füge aber eine Funktionalität ein, wo man die andere Möglichkeit zusätzlich hat. Teilweise habe ich das auch schon, aber da kann jeder Datensatz unterschiedliche Felder haben, da kommt jetzt einfach noch was dazwischen, so dass es Feld-Definitionen für jeden Datensatz-Typ gibt und die Felder setzen sich dann aus den Tabellen-Feldern, Dynamische Typ-Felder und Dynamische Custom-Felder zusammen.

Die Berechtigungen für die für das System wichtigen Tabellen werden sowieso auf Superuser gestellt und in die Doku kommt dann eine Warnung über das besagte Verhalten.

Dann hat man die Möglichkeit bequem über's Interface die Tabelle zusammenzuklicken, zu ändern, etc. und sobald ein paar Daten drin sind sollte das halt nicht mehr geändert werden, sondern lieber über die dynamischen Felder gearbeitet werden.

Das gefällt mir.

Thx euch beiden.