dot-netasp.netdatabasesql-server-2005database-design

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

просмотры: 4.7K

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

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

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

Источник

Ответов (4)

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

User(UserID, UserName, ...)

PreferenceDataType(PreferenceDataTypeID, PreferenceDataTypeName)

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

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

UserHasPreference(UserID, PreferenceID, PreferenceDataValueID)
Источник

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

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 для поля настроек, поэтому это могут быть разные типы данных, и записывать тип данных параметра как часть определения параметра в таблице параметров, чтобы вернуть его к правильному типу при запросе.

Источник

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

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

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

Источник

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

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

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

Источник