За всичко, което е винаги задайте за всеки потребител, трябва да сте склонни да го запазите в Users
таблица, според обичайната нормализация. Що се отнася до конфигурацията по избор, обичам да харесвам следната структура на таблицата:
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
Където User_Settings.type
указва дали полето за цяло число или низ трябва да се препраща.
т.е.:
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');
И за проблема INSERT/UPDATE:
INSERT INTO User_Settings (user_id, name, type, value_str) VALUES (1, 'lang', 0, 'fr')
ON DUPLICATE KEY UPDATE value_str='fr';
Освен това, както повечето други хора казват, сериализирането и съхраняването на предпочитанията не е особено добра идея, защото:
- Не можете да извлечете една стойност със заявка, трябва да извлечете целия сериализиран низ, да го десериализирате и да изхвърлите ненужните данни.
- Лесно е повреден и труден за възстановяване.
- Много е трудно да се напише необработена заявка, т.е. да се коригира глобално определена настройка.
- Съхранявате това, което по същество са таблични данни в едно поле на таблицата.
Ретроспективна редакция от септември 2016 г.:
През това време имах няколко спора с хората за това как най-добре да съхранявам незадължителните настройки, както и общата структура на таблицата, дефинирана по-горе.
Макар че структурата на таблицата не е съвсем лоша , не е точно добър или. Опитва се да направи най-доброто от лошата ситуация. Сериализацията на незадължителните настройки може да работи, стига да можете да се съобразите с тези настройки:
- Всички се зареждат наведнъж, без бране или избор.
- Не може да се индексира, търси или лесно се променя масово .
Тогава може да помислите за добавяне на поле като optional_settings
в Users
таблица, съдържаща сериализирана [напр.:JSON] форма на настройките. Можете да размените горното, но това е по-прост подход и можете да съхранявате по-сложни настройки.
Също така, ако използвате LOB тип като TEXT
за съхранение данните не се съхраняват непременно "в реда" поне в MySQL.
Както и да е, зависи от ти за да определите какви са изискванията и ограниченията на вашето приложение и да направите най-добрия избор въз основа на тази информация.