Дизайн таблицы базы данных «Предпочтения пользователя»

Question

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

Итак, другая идея, которую я придумал, состояла в том, чтобы разделить сами предпочтения на их собственную таблицу, а затем иметь строку PER preference PER user в таблице пользовательских настроек; однако это означало бы, что каждое предпочтение должно быть одного и того же типа данных, что также не кажется мне привлекательным.

Итак, мой вопрос: каков наилучший / наиболее логичный способ разработки базы данных для хранения пользовательских предпочтений?

Answer 1

Некоторые идеи, которых я стараюсь избегать в работе с базами данных, - это дублирование данных и ненужные сложности. Вы также хотите избежать " аномалий вставки, обновления и удаления ". Тем не менее, сохранение пользовательских предпочтений в одной таблице с каждой строкой = один пользователь и столбцы, с различными доступными предпочтениями, имеет смысл.

Теперь, если вы видите, что эти предпочтения используются в любой другой форме или моде в вашей базе данных, например, для нескольких объектов (не только пользователей), использующих одинаковые предпочтения, тогда вы захотите пойти по второму маршруту и ​​ссылаться на предпочтения с парами FK / PK.

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

Answer 2

Если вы сохраните все свои пользовательские настройки в одной строке таблицы User, у вас будет кошмар обслуживания!

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

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

Answer 3

Я обычно делаю это:

Users table (user_id, .... etc.)
.
Options table (option_id, data_type, ... etc.)
(list of things that can be set by user)
.
Preferences table (user_id, option_id, setting)

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

Answer 4

Очень быстро, один метод:

User(UserID, UserName, ...)

PreferenceDataType(PreferenceDataTypeID, PreferenceDataTypeName)

PreferenceDataValue(PreferenceDataValueID, PreferenceDataTypeID, IntValue, VarcharValue, BitValue, ...)

Preference(PreferenceID, PreferenceDataTypeID, PreferenceName, ...)

UserHasPreference(UserID, PreferenceID, PreferenceDataValueID)