Für alles, was immer ist für alle festlegen user sollten Sie dies eher in Users belassen Tabelle, pro üblicher Normalisierung. Was die optionale Konfiguration anbelangt, bevorzuge ich die folgende Tabellenstruktur:
TABLE Users:
id INT AI
name VARCHAR
...
TABLE User_Settings
user_id INT PK,FK
name VARCHAR PK
type BOOL
value_int INT NULL
value_str VARCHAR NULL
Wobei User_Settings.type gibt an, ob auf das Integer- oder das String-Feld verwiesen werden soll.
dh:
INSERT INTO Users (id, name) VALUES (1, 'Sammitch');
INSERT INTO User_Settings (user_id, name, type, value_int) VALUES (1, 'level', 1, 75);
INSERT INTO User_Settings (user_id, name, type, value_str) VALUES (1, 'lang', 0, 'en');
Und für das INSERT/UPDATE-Problem:
INSERT INTO User_Settings (user_id, name, type, value_str) VALUES (1, 'lang', 0, 'fr')
ON DUPLICATE KEY UPDATE value_str='fr';
Wie die meisten anderen Leute auch sagen, ist das Serialisieren und Speichern der Einstellungen keine besonders gute Idee, weil:
- Sie können keinen einzelnen Wert mit einer Abfrage abrufen, Sie müssen den gesamten serialisierten String abrufen, ihn deserialisieren und die unnötigen Daten verwerfen.
- Es ist leicht zu korrumpieren und schwer zu beheben.
- Es ist mühselig, eine rohe Abfrage zu schreiben, dh um eine bestimmte Einstellung global zu korrigieren.
- Sie speichern im Wesentlichen tabellarische Daten in einem einzigen Tabellenfeld.
September 2016 Retrospektive Bearbeitung:
In der Zwischenzeit hatte ich ein paar Auseinandersetzungen mit Leuten darüber, wie man am besten optionale Einstellungen sowie die oben definierte allgemeine Tabellenstruktur speichert.
Dabei ist diese Tabellenstruktur nicht unbedingt schlecht , es ist nicht gerade gut entweder. Es versucht, das Beste aus einer schlechten Situation zu machen. Die Serialisierung optionaler Einstellungen kann funktionieren, solange Sie diese Einstellungen berücksichtigen können:
- Alles wird auf einmal geladen, kein Auswählen oder Aussuchen.
- Nicht indexierbar, durchsuchbar oder massenhaft leicht änderbar .
Dann könnten Sie erwägen, ein Feld wie optional_settings hinzuzufügen in den Users Tabelle, die eine serialisierte [zB:JSON] Form der Einstellungen enthält. Sie tauschen das obige aus, aber es ist ein einfacherer Ansatz und Sie können komplexere Einstellungen speichern.
Auch, wenn Sie einen LOB-Typ wie TEXT verwenden zur Speicherung werden die Daten zumindest in MySQL nicht unbedingt "in the row" gespeichert.
Wie auch immer, es liegt an dir um die Anforderungen und Einschränkungen Ihrer Anwendung zu ermitteln und auf der Grundlage dieser Informationen die beste Wahl zu treffen.
