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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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