2009-02-16 5 views
14

Лучше расширить мою бизнес-базу данных таблицами модели безопасности членства в ASP.NET. Или я должен иметь другое хранилище данных, где я управляю только Identities and Roles ... В основном 1 или 2 базы данных?Best Practice ASP.NET Membership: Пользовательские таблицы в одном хранилище данных?

ответ

2

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

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

Так что нет, я бы никогда не использовал два. Однако я мог бы использовать три.

+0

три? У вас есть свои роли? Или какая у вас настройка? – 2009-02-16 14:08:03

+0

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

3

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

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

0

Какую платформу базы данных используете? Если тот, который поддерживает схемы в базе данных, например. SQL Server 2008, то вы можете поместить свои таблицы членства в свою схему, для аккуратности. Вы также можете добавить внешние ключи перекрестной схемы, если это необходимо.

+0

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

+1

Если это так, то, предположительно, вы используете схему dbo только для элементов членства и ставите все остальное в другом месте? Возможно, это не самый элегантный обходной путь, но, возможно, еще более аккуратный, чем элементы принадлежности, связанные со всем остальным? –

 Смежные вопросы

  • Нет связанных вопросов^_^