Til alt, der altid er indstillet til hver bruger bør du have en tendens til at beholde det i Users
tabel, efter sædvanlig normalisering. Hvad angår valgfri konfiguration, har jeg en tendens til at kunne lide følgende tabelstruktur:
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
Hvor User_Settings.type
angiver, om der skal refereres til heltal- eller strengfeltet.
dvs.:
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');
Og for INSERT/UPDATE-problemet:
INSERT INTO User_Settings (user_id, name, type, value_str) VALUES (1, 'lang', 0, 'fr')
ON DUPLICATE KEY UPDATE value_str='fr';
Som de fleste andre siger, er det heller ikke en særlig god idé at serialisere og gemme præferencerne, fordi:
- Du kan ikke hente en enkelt værdi med en forespørgsel, du skal hente hele den serialiserede streng, de-serialisere den og kassere de unødvendige data.
- Det er let at ødelægge og svært at komme sig fra.
- Det er kedeligt at skrive en rå forespørgsel til, dvs. at rette en bestemt indstilling globalt.
- Du gemmer, hvad der i det væsentlige er tabeldata i et enkelt tabelfelt.
Sept 2016 Retrospektiv redigering:
I den mellemliggende tid har jeg haft et par skænderier med folk om, hvordan man bedst gemmer valgfrie indstillinger, såvel som den generelle tabelstruktur defineret ovenfor.
Selvom den tabelstruktur ikke direkte er dårlig , det er ikke ligefrem godt enten. Den forsøger at få det bedste ud af en dårlig situation. Serialisering af valgfrie indstillinger kan fungere, så længe du kan rumme disse indstillinger:
- Alle bliver indlæst på én gang, ingen plukning eller valg.
- Ikke indekserbar, søgbar eller let ændret masse .
Så kan du overveje at tilføje et felt som f.eks. optional_settings
i Users
tabel, der indeholder en serialiseret [fx:JSON]-form af indstillingerne. Du afvejer ovenstående, men det er en mere ligetil tilgang, og du kan gemme mere komplekse indstillinger.
Også, hvis du bruger en LOB-type som TEXT
til lagring er dataene ikke nødvendigvis gemt "i rækken" i det mindste i MySQL.
Under alle omstændigheder er det op til dig for at bestemme, hvad din applikations krav og begrænsninger er, og træffe det bedste valg baseret på disse oplysninger.