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

Question

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

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

Спасибо.

Answer 1

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

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

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

или

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

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

Answer 2

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

1. Users : таблица со строкой на пользователя для свойств, которые пользователь, вероятно, всегда будет иметь, например, имя пользователя и пароль.В этой таблице также могут храниться внешние ключи, но это эвристический метод, который также зависит от отношения ноль-к-1 или ноль-ко-многим.Если для последнего требуется отдельная таблица.
2. Функции : два варианта
   1. таблица со строкой на объект, фактически хэш-таблица со столбцами userId, name и value.Это также может быть местом для внешних связей, но вы не сможете обеспечить целостность данных в этой настройке.
   2. XML, но только с базой данных, имеющей функции, которые позволяют запрашивать данные, или только для данных, которые вам не нужно запрашивать, а работают только на вашем сервере приложений.

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

Answer 3

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

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