Использовать профиль ASP.NET или нет?

Question

Мне нужно сохранить несколько атрибутов аутентифицированного пользователя (я использую Membership API), и мне нужно сделать выбор между использованием профилей или добавлением новой таблицы с UserId в качестве PK. Похоже, что использование профилей является быстрым и требует меньше работы заранее. Тем не менее, я вижу следующие недостатки:

1. Значения профиля сводятся в один столбец ntext. В будущем у меня появятся сценарии SQL, которые могут обновлять атрибуты пользователя. Запрос столбца ntext и попытка обновить значение звучит для меня немного ошибочно.
2. Если я решу добавить новое пользовательское свойство и захочу назначить значение по умолчанию для всех существующих пользователей, будет ли это возможно?

Моим первым впечатлением было то, что использование профилей в долгосрочной перспективе может вызвать проблемы с обслуживанием. Мысли?

Answer 1

В MSDN была статья (теперь в ASP.NET http://www.asp.net/downloads/sandbox/table-profile-provider-samples)), в которой обсуждается, как сделать поставщика таблицы профилей. Идея состоит в том, чтобы хранить данные профиля в таблице вместо строки, упрощая запрос только с SQL.

Более подробно об этом: SQL Server 2005/2008 обеспечивает поддержку для получения данных с помощью служб и кода CLR. Вы могли бы получить доступ к данным профиля через API вместо базовых таблиц напрямую.

Что касается пункта # 2, вы можете установить значения по умолчанию для свойств, и, хотя это не приведет к немедленному обновлению других профилей, профиль будет обновляться при следующем доступе к нему.

Answer 2

Проверить этот вопрос ...

Встроенный профиль пользователя ASP.NET по сравнению со старым пользовательским классом / таблицами

Первый намек на то, что встроенные профили плохо спроектированы, - это использование данных с разделителями в реляционной базе данных. Есть несколько случаев, когда данные в СУРБД с разделителями имеют смысл, но это определенно не один из них.

Если у вас нет конкретной причины до использовать профили ASP.Net, я бы рекомендовал вместо этого использовать отдельные таблицы.

Answer 3

Мне кажется, вы ответили на свой вопрос. Если ваша точка 1 вероятна, то единственно разумным вариантом является таблица SQL.