Каков наилучший способ сохранить тривиальные пользовательские состояния (например, отклоненные приветственные сообщения) в базе данных?

Question

Должен ли я использовать (создавать) столбец для каждого нового состояния? Или одно поле с кучей разделенных запятыми состояний (или json obj)? Любые предложения приветствуются.

UPDATE

Сначала позвольте мне поблагодарить вас за ответы. Я просто хочу уточнить, какие варианты я вижу:

1. Поместить столбец для каждого состояния в строке пользователя (первоначальный план) / Может запутаться с большим количеством состояний (в будущем)
2. Поместить один столбец с данными json / xml в строку пользователя / Легко поддерживать (не требуется изменение базы данных), но не выглядит правильным
3. Имейте специальную таблицу состояний (thx lhiles ) / Звучит круто, как бы эта таблица выглядела?

Я ищу плюсы / минусы различных реализаций. Еще раз: спасибо!

Answer 1

Создать столбец для каждого состояния.Это правильная нормализация данных.

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

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

Позволяет легко добавлять ограничения для каждого состояния по мере необходимости.(Состояние X может содержать только «1» или «2».)

Позволяет легко запрашивать состояния у разных пользователей.(Сколько пользователей установили значение состояния «X»?)

Answer 2

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

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

Недавно я сделал что-то, что я указал выше.Теперь, чтобы добавить новый параметр, я добавляю запись в enum и все.Новые настройки занимают около 10 секунд.

Я могу поместить свой код в CodeProject, это облегчает разработку.

Answer 3

Вы можете сохранить состояние, используя ENUM, если состояния являются взаимоисключающими;Например, человек является мужчиной или женщиной.
Или используя SET, если состояния могут сосуществовать;Например, человек является членом (AA и CA и SOsA *)

Пример таблицы с использованием обоих:

CREATE TABLE test.table1(
  test_enum ENUM('male', 'female') DEFAULT 'male',
  test_set SET('AA', 'CA', 'SOsA') DEFAULT NULL
)
ENGINE = INNODB;

Если вы используете ENUM, я лично рекомендую вам установитьявное значение по умолчанию, отличное от null, поскольку в большинстве случаев необходимо сделать выбор.

Ссылка: http://dev.mysql.com/doc/refman/5.1/en/constraint-enum.html

* (анонимные страдальцы stackoverflow)

Answer 4

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

Другим способом, если вы чувствуете, что будет слишком много настроек, чтобы выделять 1 настройку на столбец, будет сохранение настроек в виде данных XML (или, как вы упомянули, json) в SQL. Это позволило бы вам получить любой тип формата состояния, который вы хотели, однако, это потребовало от программиста больше работы по анализу, проверке и сохранению этих настроек.