Сохранение пользовательских настроек в таблице - как?

Question

У меня есть настройки для пользователя около 200 настроек, к ним относятся настройки уведомлений и параметры отслеживания от действий пользователя на объектах. Проблема в том, как сохранить его в БД? Должны ли каждая настройка быть строкой или столбцом? Если colunm тогда таблица будет иметь 200 колоний. Если строка, то около 3 колонок, но 200 строк на пользователя x даже 10 миллионов пользователей = не хорошо.

Так как же я могу сохранить все эти настройки? ПРИМЕЧАНИЕ. Эти параметры представляют собой сочетание ввода текста и поиска FK с другими таблицами.

Спасибо.

Answer 1

Что у вас есть 200 настроек для отслеживания, предлагает гибкую схему базы данных. Поэтому я хотел бы предложить гибридный подход:

1. Пользователи: таблицу с строкой для каждого пользователя для свойств, которые пользователь, вероятно, всегда будет иметь, например, имя пользователя и пароль. В этой таблице также могут храниться внешние ключи, но это эвристика, а также зависит от отношения нуля от нуля или от нуля до многих. Если последний требует отдельной таблицы.
2. Особенности: два варианта
   1. стол с ряда на функции, эффективно Hashtable, с USERID, имя и значение столбцов. Это также может быть местом для внешних отношений, но вы не сможете обеспечить целостность данных в этой настройке.
   2. XML, но только с базой данных, которая имеет функции, позволяющие запрашивать данные или только данные, которые вам не нужны, но работают только на вашем сервере приложений.

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

Answer 2

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

Можете ли вы попробовать XML для всех этих 200 настроек, а затем у вас будет только 1 строка на пользователя. имя пользователя и соответствующие настройки xml. Но опять же это ограничит ваши возможности запросов, но теперь базы данных поддерживают XML. Вы можете специально проверить XML-базы данных.

Answer 3

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

Если у вас есть логика приложения подключили к каждой настройки, я думаю, вы должны реализовать его либо как:

1 колонка за настройки в таблице настроек. Это упрощает использование мощности ваших dbms, проверку ограничений, ссылочную целостность, правильный тип данных для ваших значений, большое количество информации для оптимизатора. Недостатком является то, что размер строки растет.

или

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

Кроме того, множество столбцов часто является «запахом», что предполагает, что вы не нормализировали свои данные правильно, но это не обязательно должно быть так. Только вы знаете свои данные.