Использовать Профиль ASP.NET или нет?
Я должен сохранить несколько атрибутов аутентифицируемого пользователя (я использую Членство API), и я должен сделать выбор между использованием Профилей или добавлением новой таблицы с UserId как PK. Кажется, что использование Профилей быстро и нуждается в меньшем количестве работы заранее. Однако я вижу следующие оборотные стороны:
- Значения профиля хлюпаются в единственный столбец типа ntext. В какой-то момент в будущем, у меня будут сценарии SQL, которые могут обновить атрибуты пользователя. Запросы столбца типа ntext и попытка обновить значение звучат как немного багги мне.
- Если я приму решение добавить нового пользователя определенное свойство и буду хотеть присвоить значение по умолчанию для всех существующих пользователей, то это будет возможно?
Мое первое впечатление было то, что использование профилей может вызвать maintainance головные боли в конечном счете. Мысли?
3 ответа
На MSDN (теперь на ASP.NET http://www.asp.net/downloads/sandbox/table-profile-provider-samples) была статья о том, как сделать Profile Table Provider. Идея заключается в том, чтобы хранить данные профиля в таблице, а не в строке, что облегчает выполнение запросов с помощью SQL.
Более того, SQL Server 2005/2008 поддерживает получение данных через службы и код CLR. Вполне возможно, что вы сможете получить доступ к данным профиля через API вместо непосредственного доступа к базовым таблицам.
Что касается пункта #2, вы можете установить значения по умолчанию для свойств, и хотя это не приведет к немедленному обновлению других профилей, профиль будет обновлен при следующем обращении к нему.
Проверьте этот вопрос ...
Первый намек на то, что встроенные профили плохо спроектированы, - это использование ими данных с разделителями в реляционная база данных. Есть несколько случаев, когда разделение данных в РСУБД имеет смысл, но это определенно не один из них.
Если у вас нет особой причины для использования профилей ASP.Net, я бы посоветовал вам вместо этого использовать отдельные таблицы.
Мне кажется, вы ответили на свой вопрос. Если ваш пункт 1, скорее всего, произойдет, тогда таблица SQL - единственный разумный вариант.