MySQL Datenbank Strucktur für Settings

[sniper]

hi,

aber ich habe das Gefühl, dass ich mit dieser Struktur auf der falsch liege oder?

Ne, falsch ist das nicht, aber...

Denn ich kann ja nicht jedes Feld anlegen oder?

...genau hier liegt der Karnickel in der Pfeffersoße: Dein Programm wird vom DB-Design abhängig und Änderungen am Programm erfordern Änderungen am DB-Design.

wenn ich aber jeden Wert in eine Spalte lege, dann wird diese verdammt lang. Wie würdet ihr dieses machen? Und wie kann ich solltet ihr dieses anderes machen, die einzelnen Werte auslesen?

So mancher DB-Designer kennt da nix und legt Tabellen an mit 20..50 Spalten, das wird jedoch sehr schnell zu Schrott. Eine mögliche andere Lösung besteht darin, eine Basistabelle zu haben und eine weitere, nicht normalisierte Tabelle für die Attribute.

Die Basistabelle hat nur eine Handvoll Felder, eine Abfrage select * from ... where id = ... liefert performante Abfragen und eine Liste weniger Attribute für eine bestimmte ID. An dieser Tabelle ist nur selten was zu ändern und die Datenmengen der Abfragen sind klein, womit auch mehrere solcher Array's im Hauptspeicher liegen können, auch bei jedem Request.

Das Los der Attribute hingegen, wird nur dann geladen, wenn es tatsächlich gebraucht wird. Das ist dann eine größere Liste und u.U. sind da auch größere Datenmengen je Attribut drin, wie z.B. der BODY für die Response. Es gibt Modelle für die Datenabstraktion, da wird aus der Sicht der Anwendung ein komplettes Array aus der DB geholt und nicht etwa einzelne Werte abgefragt. Ein solches Array ist assoziativ, die Namen der Attribute haben mit DB-Feldnamen nichts mehr gemeinsam. Die Attribute liegen namentlich in einer Tabelle mit dem zugehörigen Wert, das Modell heißt Entity-Attribute-Value, das ist recht einfach zu implementieren.

Gus