Voor alles dat altijd is ingesteld voor elke gebruiker, u moet de neiging hebben om dat in de Users
. te bewaren tabel, per gebruikelijke normalisatie. Wat betreft optionele configuratie houd ik meestal van de volgende tabelstructuur:
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
Waar User_Settings.type
specificeert of er naar het integer- of stringveld moet worden verwezen.
dat wil zeggen:
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');
En voor het INSERT/UPDATE-probleem:
INSERT INTO User_Settings (user_id, name, type, value_str) VALUES (1, 'lang', 0, 'fr')
ON DUPLICATE KEY UPDATE value_str='fr';
Bovendien, zoals de meeste andere mensen zeggen, is het serialiseren en opslaan van de voorkeuren geen bijzonder goed idee, omdat:
- Je kunt geen enkele waarde ophalen met een query, je moet de hele reeks met serienummers ophalen, de-serialiseren en de onnodige gegevens weggooien.
- Het is gemakkelijk te beschadigen en moeilijk te herstellen.
- Het is lastig om een onbewerkte query voor te schrijven, dat wil zeggen:om een bepaalde instelling globaal te corrigeren.
- Je slaat in wezen tabelgegevens op in een enkel tabelveld.
September 2016 Retrospectief bewerken:
In de tussenliggende tijd heb ik een paar discussies gehad met mensen over de beste manier om optionele instellingen op te slaan, evenals de algemene tabelstructuur die hierboven is gedefinieerd.
Hoewel die tabelstructuur niet ronduit slecht is , het is niet bepaald goed een van beide. Het probeert het beste te maken van een slechte situatie. Serialisatie van optionele instellingen kan werken zolang u deze instellingen kunt aanpassen:
- Alles wordt tegelijk geladen, niet kiezen of kiezen.
- Niet indexeerbaar, doorzoekbaar of gemakkelijk te wijzigen en masse .
Dan zou je kunnen overwegen om een veld toe te voegen zoals optional_settings
in de Users
tabel met een geserialiseerde [bijv:JSON] vorm van de instellingen. U ruilt het bovenstaande in, maar het is een meer rechtlijnige benadering en u kunt complexere instellingen opslaan.
Ook als u een LOB-type gebruikt zoals TEXT
voor opslag worden de gegevens niet noodzakelijkerwijs "in de rij" opgeslagen in MySQL.
Hoe dan ook, het is aan jij om te bepalen wat de vereisten en beperkingen van uw toepassing zijn, en op basis van die informatie de beste keuze te maken.