Лучший способ хранения пользовательских настроек в MySQL?

Для всего, что всегда задано для каждого пользователя, вы должны придерживаться этого в таблице « 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 указывает, следует ли 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'; 

Кроме того, как говорят многие другие люди, сериализация и сохранение предпочтений не является особенно хорошей идеей, потому что:

1. Вы не можете получить одно значение с запросом, вы должны получить всю сериализованную строку, де-сериализовать ее и отказаться от ненужных данных.
2. Это легко повредить и трудно оправиться.
3. Это боль в добыче, чтобы написать необработанный запрос, т. Е. Глобальное исправление определенной настройки.
4. Вы сохраняете то, что по сути является табличными данными в одном поле таблицы.

Сентябрь 2016 Ретроспектива Редактировать:

В промежуток времени у меня было несколько аргументов с людьми о том, как лучше хранить дополнительные настройки, а также общую структуру таблицы, определенную выше.

Хотя эта структура таблицы не совсем плоха , это тоже не очень хорошо . Он пытается сделать лучшее из плохой ситуации. Сериализация дополнительных настроек может работать до тех пор, пока вы можете разместить эти настройки:

1. Все загружаются сразу, без выбора или выбора.
2. Не быть индексируемым, доступным для поиска или легко модифицироваться в массовом порядке .

Тогда вы можете подумать о добавлении поля, такого как optional_settings в таблицу Users содержащую сериализованную [например: JSON] форму настроек. Вы торгуете выше, но это более простой подход, и вы можете хранить более сложные настройки.

Кроме того, если вы используете тип LOB типа TEXT для хранения, данные не обязательно сохраняются «в строке», по крайней мере, в MySQL.

Во всяком случае, вам решать, какие требования и ограничения вашего приложения есть, и сделать лучший выбор на основе этой информации.

Второй вариант, но измененный с сохранением настроек отдельно. Не храните сериализованные данные в поле, так как в этом случае это плохая практика.

Подумайте об этом: у вас это есть, и вы храните там страну пользователя или зарегистрирован в своем бюллетене. Позже … вам нужно знать, сколько людей из России. Чем ты занимаешься? Возьмите их один за другим и расшифруйте их и увеличьте счетчик? (или используя ваш второй метод и просто запустите простой запрос SELECT COUNT (id)?)

Это всегда одна и та же проблема: как часто вам нужно менять эти данные? По-моему, наличие отдельной таблицы всегда является хорошим решением, поскольку оно разделяет различные аспекты вашего приложения.

Имея колонки preferences это не очень хорошая идея, ИМХО, потому что всякий раз, когда ваш пользователь меняет свои настройки, вам придется сериализовать все свои данные для их хранения в таблице users , будь то просто update с отдельным. Если вы действительно хотите хранить все в users , вы должны разделить свои настройки в разных столбцах.

Все зависит от настроек и схемы вашей базы данных. Независимо от того, что вы делаете, я бы рекомендовал не сериализовать данные в соответствии с вашим предложением 1, если вы сериализуете данные, которые больше не сможете писать запросы против него, и вам нужно будет десериализовать его, используя тот же язык, с которого вы его сериализовали (или напишите что-то сопоставимое в этот язык).

Вариант, который я бы рекомендовал, заключается в установке параметров в таблицу users, 1 для каждого столбца. Недостатком этого является добавление нового параметра в приложение, вам нужно будет написать некоторый DDL-скрипт, чтобы добавить новый столбец. Одно (очень хорошее) преимущество в этом состоит в том, что каждый параметр может иметь свой собственный тип данных. Это также будет иметь штраф хранения, если этот параметр является необязательным.

Другим вариантом может быть использование таблицы параметров, как вы предложили, с первичным ключом (user_id, имя_пользователя) с третьим столбцом значения настройки. Это решение предполагает, что все настройки имеют один и тот же тип данных. Вам не нужно писать сценарий DDL для добавления нового параметра, просто используйте новое имя ключа.

Я бы пошел с таблицей настроек, потому что это облегчит доступ позже. Когда вы пытаетесь сделать что-то вроде создания пар значений в одном столбце, вы можете столкнуться с проблемами позже, пытаясь спроектировать запросы для доступа к данным.

Возможно, это не подходит для вашей текущей ситуации, но базы данных NoSQL (например, Mongo) отлично подходят для этого. Например, это база данных mongo, каждый пользовательский объект может иметь разные свойства, и вы можете искать их.

Тем не менее, в той ситуации, в которой вы находитесь, в прошлом я следил за тем, что предлагает другие ответы, и имела отдельную таблицу. Это можно сделать двумя способами: у вас есть отдельная таблица, в которой вы более удобны для изменения столбцов и присоединяетесь к ней. ИЛИ, более простое решение, имеющее отдельную таблицу, такую ​​как,

Пользователь, Параметр, Значение.

Тогда каждый пользователь может иметь разные дополнительные значения.

Лучший подход зависит от требуемой производительности и т. Д.