最佳实践 ASP.NET 成员资格：同一数据存储中的用户表？
使用 ASP.NET 成员安全模型的表扩展我的业务数据库是否更好？ 或者我应该有一个不同的数据存储，只管理身份和角色......基本上是 1 或 2 个数据库？
Is it better to extend my business database with the tables of the ASP.NET Membership Security model. Or should I have a different datastore where I only manage Identities and Roles... Basically 1 or 2 databases?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这可能取决于规模。 如果它是一个企业解决方案，不同的应用程序共享一个会员源，那么答案很简单 - 将它们分开。 也可能出于性能原因，您希望将此数据与应用程序的其余部分分开。 例如，可以说这些表不属于数据仓库。
2 个数据库解决方案唯一无法提供的是引用完整性。 如果您扩展成员资格表以保存更多有关用户的应用程序特定详细信息，并且这些表需要链接到主数据库，那么您可能希望将它们放在一起。 否则，您将需要某种复制作业来为您维护这一点。
This can depend on scale. If it's an enterprise solution with different apps sharing one membership source the answer is simple - separate them. There might also be performance reasons why you would want to separate this data from the rest of the app. Arguably these tables do not belong in a data warehouse for example.
The only thing the 2 databases solution doesn't give you is referential integrity. If you extend your membership tables to hold more application specific details about the user, and these tables need to link into the main database then you might want to keep them together. Otherwise you would need some sort of replication job maintaining this for you.
这是相当主观的，但除非这些用户将使用多个数据库，否则我会说将它们保留在同一个数据库中。
如果用户和角色在多个数据库中使用，我只会为用户和角色使用单独的数据库。
所以不，我永远不会使用两个。 不过我可能会用三个。
This is quite subjective, but unless those users are going to be using more than one database, then I'd say keep them in the same db.
I would only use a separate database for users and roles if those users and roles were used in more than one database.
So no, I'd never use two. I might however use three.
您使用哪个数据库平台？ 如果数据库支持模式（例如 SQL Server 2008），那么您可以将成员资格表放入其自己的模式中，以保持整洁。 如果需要，您还可以添加跨架构外键。
Which database platform are you using? If one that supports schemas within a database, e.g. SQL Server 2008, then you can put your membership tables into their own schema, for neatness. You can also add cross-schema foreign keys if required.