Как совместить использование API членства с данными, относящимися к собственному приложению?

Разрабатывая новое приложение на asp.net 4, я должен принять решение, как использовать API членства в MS SQL вместе с моими собственными данными в базе данных MS SQL. Во-первых, мне нужно хранить данные профиля пользователя и получать к ним доступ более гибким образом, чем это поддерживает поставщик профиля. Во-вторых, я хотел бы связать другую информацию, связанную с пользователем (например, заказы).

Независимо от того, где вы храните таблицы aspnetdb (в отдельной базе данных или в той же базе данных, что и ваши данные),проблема заключается в том, как поддерживать синхронизацию данных.

После исследования я вижу следующие подходящие варианты:
1. UserId внешнего ключа от asp_Users (предлагается в в этом руководстве).
2. Нет внешнего ключа - используйте транзакции (предлагается здесь ).
3. Нет внешнего ключа - используйте индивидуальный AccountController (какой бы он ни был, предлагается здесь ).
4. Дополнительная таблица, которая связывает пользовательский идентификатор членства (uid) с пользовательским идентификатором пользователя (int).
5. ...

С одной стороны, мне нравится первое решение, поскольку оно довольно простое и предлагается в официальном руководстве по asp.net.

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

Итак, как лучше всего подойти к этому? Кроме того, как будет выглядеть реализация? Достаточно ли будет использовать только дополнительный код ADO.NET или LINQ и т. Д., Или стоит реализовать собственный поставщик членства и / или профиля?

Заранее благодарим.