Как наилучшим образом использовать базу данных членства ASP .NET?

Question

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

• Членство создает новую базу данных. Какой из них лучше, чтобы использовать ту же базу данных для моего база данных приложения ИЛИ создание новой базы данных для моего приложения? Зачем?
• Если я пойду для создания новой базы данных для моего приложения. Какой из них лучше: создать новую пользовательскую таблицу в базе данных моего приложения или повторно использовать / расширить пользовательскую таблицу в базе данных членства?

Заранее спасибо,

RWendi

Answer 1

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

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

Answer 2

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