Выбор модели для хранения сложных динамических пользовательских профилей / настроек - PullRequest
Новая
       13

Выбор модели для хранения сложных динамических пользовательских профилей / настроек

0 голосов
/ 24 августа 2011

Вот макет :

  • Я разрабатываю внутреннее веб-приложение ASP.NET (в VB.NET) с базой данных SQL Server.
  • Так как мои пользователи строго внутренние, я использую метод "Windows" для автоматической аутентификации.
  • У меня есть четыре пользовательских роли, каждая из которых имеет свой уникальный и динамический набор настроек.
  • БОНУС: У каждого пользователя может быть несколько ролей и, следовательно, несколько профилей.

Из моего обширного исследования я определил следующие два метода для хранения настроек профиля пользователя (оба из которых вызывают вопрос «КАК?»), Хотя я не уверен, , что лучше (если есть):

  • Сохранение профилей и связанных с ними настроек в БД (Какую структуру использовать? Из предварительного сопоставления я создал как минимум четыре таблицы, которые начинают становиться совершенно неуправляемыми и неуправляемыми)
  • Использовать встроенный объект членства и профиля ASP.NET ? (Я не могу найти хороший учебник по этому вопросу. Требует ли этот метод поддержки БД? Опять же, с использованием какой структуры таблицы?) - Меня больше всего интересует это возможное решение
* +1032 * Пример: * 1 033 *

Моей самой сложной группе пользователей требуется возможность сохранять профиль всех (выбранных пользователем) продуктов, связанных с пользователем. Скажем, я менеджер по продукту и хочу, чтобы в моем аккаунте показывались все продукты, которые я выбрал, за которые я отвечаю. Очевидно, что каждый член моей роли будет иметь разные продукты и разное их количество и т. Д. Возможно, настройки страницы пользователя (например, поиск, сортировка, настройки по умолчанию и т. Д.) Могут быть сохранены в общей таблице с ссылка на таблицу вспомогательных настроек для странных вещей, которые могут быть связаны с помощью специальной записи, которая может выступать в качестве «внешнего ключа».

По запросу одна моих идей для плана стола: 

    Users (ID, Username, RoleID)
    Roles (ID, RoleName, Description) --Lookup Table
    Settings (ID, Name, Value)
    UserSettings (ID, UserID, SettingID) --Junction Table

Тогда возникают вопросы:

  1. Когда мне использовать строку против столбца?
  2. Если я использую столбец для каждого параметра, я могу определить типы данных, но количество столбцов может выйти из-под контроля. С другой стороны, если я использую строку для параметра, это имеет гораздо больший смысл, но я теряю контроль над типом данных для параметра.
  3. Должен ли я опустить таблицу UserSettings и просто добавить запись пары имя = значение для каждого параметра в таблице настроек с помощью внешнего ключа UserID?
  4. и т. Д. И т. Д. *

Мой идеальный ответ:

Как видите, у меня много вопросов, и я нашел, по-видимому, небольшую помощь. Я бы ЛЮБОВЬ это, если бы кто-то мог сломать это для меня в простых терминах . Скажите, пожалуйста, свои профессиональные рекомендации и несколько очень простых советов о том, как его реализовать (например, какие объекты ASP.NET использовать, а также о том, как указанные объекты предоставляют механизм для управления моим сложные профили)

1 Ответ

1 голос
/ 24 августа 2011

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

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

Тогда у пользователя, выступающего в роли менеджера, могут быть определенные продукты, а у продавца - другие продукты.Тогда роль будет также в таблице ссылок.Иногда строки таблицы ссылок имеют атрибуты о связи, а не только сами связи (обычно такие вещи, как даты вступления в силу и флаги активности / деактивации).

...