Tabellenstruktur

Ich habe mal eine Frage.. (es handelt sich um eine User-Klasse)

Ich verwende derzeit eigentlich immer die normale Struktur also z.B. (Userdaten)

id, status, account, password, name, email, adress, zip, city

Jetzt möchte ich aber eine 'offene' Struktur wo das Script nicht nur eine festgelegte Menge von Daten bearbeiten kann sondern wo man einfach mal sagen kann, dass auch die Daten "Telefonnummer", "Geburtstag" und "Homepage" mitgespeichert werden sollen.

In der festen Tabellenstruktur kann man natürlich nicht mal eben die Daten einfügen. Deshalb dachte ich mir baust du so eine Tabelle

id, user, name, value

'user' ist die ID des Users, 'name' übernimmt den Namen des Feldes und 'value' den Wert. z.B. 'email', '[email protected]'

Im Grunde ja kein Problem und man kann das auch leicht speichern und abfragen. Ich möchte jetzt aber einmal Fragen in wie weit sich das auf Performence der Datenbank auswirkt bzw. auf was man Eurer Erfahrung nach beachten sollte.

Also wir setzen diese Zusatzinfo-Tabellen seit längerer Zeit erfolgreich ein. Eben für solche Zusatzinfos, die eher selten gebraucht werden.
Klar, das Abfragen aller Infos ist langsamer, aber dafür hat man eben bei den ständigen Hauptquerys (SELECT name FROM user WHERE blub) längst keine so große Datendatei, was sich natürlich positiv auf die Performance auswirkt.
Aber so ganz der Normalisierung entspricht es natürlich nicht.

Index auf "user" in der zweiten Tabelle sollte sein, ansonsten klar, kein Thema..

Habe Geschwader, Schiffe, Nachrichten, usw alles auf dem Schema basierend.

Sehe da auch nicht das Problem, was da generell dagegen spraeche?! Ist doch eine normale Zuordnung..

Wie speichert ihr sonst variable Mengen von Datensaetzen ab?

Das einzige was dagegen spraeche ist ja die Frage ob man das wirklich fuer jeden Kram braucht bzw. was man ueberhaupt alles speichern moechte. Selbst bei den essenziellen Dingen kommt schon eine Menge an Tabellen zusammen. Die Performance sollte aber nicht sonderlich leiden...

solche zusatzinfos die man nicht oft ändern muss und die man eigentlich nie direkt abfragt, kann man auch als serialisiertes array in einer extra tab abspeichern. hat halt den vorteil das es extrem flexibel ist und durch die auslagerung in eine extra tab wird eine eventuelle starre tabstruktur nicht beeinträchtigt

Das verstößt ja sogar gegen die 1. Normalform. Die Zusatztabellen immerhin erst gegen die 5. oder 6. (bin ich mir net ganz sicher).
Atomarität sollte man schon einhalten, zumal man ja nicht sicher sein kann, dass immer mit der gleichen Programmiersprache auf die DB zugegriffen wird.

Original von Kampfhoernchen
Das verstößt ja sogar gegen die 1. Normalform. Die Zusatztabellen immerhin erst gegen die 5. oder 6. (bin ich mir net ganz sicher).
Atomarität sollte man schon einhalten, zumal man ja nicht sicher sein kann, dass immer mit der gleichen Programmiersprache auf die DB zugegriffen wird.

gibt es nicht nur 5?
und das wär so viel ich weis die 4. Wenn ich falsch liege, dann klärt mich auf

Aber sonst würde Mudder's Beispiel der 3. Normalform entsprechen eigentlich. Wäre es aber nicht sinvoll anstat name nameid zu verwenden? und in einer 2. Tabelle die Werte die man verwenden darf? Ich geh aber mal davon aus das du das vor hattest.

Klar könnte man das auch mit name_id und ner extra Tabelle machen. Nur ganz ehrlich warum alles verkomplizieren? Nur damit man die Anfragen verdoppelt um rauszubekommen welche name_id der Wert "Adresse" hat?

Ich brauch das für ne allgemeine User.Class die ich mal eben überall einbauen kann und wo neben den Stammdaten eben auch frei andere Daten gespeichert werden können. Zur Sicherheit werde ich hier zwar ein Settings-Array mit einbauen, welche Namenswerte erlaubt sind, aber das werde ich defenitiv per Config-Datei/Settings-Attribut umsetzen.

Es gibt 6 Normalformen (die 6. ist die BF-NF), wobei ich diese nicht wirklich verstanden habe.

Original von Mudder
Klar könnte man das auch mit name_id und ner extra Tabelle machen. Nur ganz ehrlich warum alles verkomplizieren? Nur damit man die Anfragen verdoppelt um rauszubekommen welche name_id der Wert "Adresse" hat?

Ich brauch das für ne allgemeine User.Class die ich mal eben überall einbauen kann und wo neben den Stammdaten eben auch frei andere Daten gespeichert werden können. Zur Sicherheit werde ich hier zwar ein Settings-Array mit einbauen, welche Namenswerte erlaubt sind, aber das werde ich defenitiv per Config-Datei/Settings-Attribut umsetzen.

Du könntest die Namen auch in einem Array aus einer PHP-Datei laden. Das verringert den MySQL Traffic natürlich erheblich. :lol:

Das geht einfach darum das ich es für Blödsinn halte, dass man statische Werte welche man bei jedem Seitenaufruf und jedem User braucht, immer aus der DB rausholt. Nur weil das grade Mode geworden is alles in ne DB zu stecken, bleib ich bei der Ansicht das Configdateien - genauso wie z.B. Sprachdateien - deutlich besser sind als 20 Queries.

Ack.. endlich mal jemand, der auch an die Performance denkt