ASP.NET 成员资格和角色分离关系
我有一个 ASP.NET 项目，我想将成员身份（SQL 提供程序）保留在单独的数据库中，并且角色/配置文件将针对每个应用程序。
问题
会员数据库和角色/个人资料数据库之间关联的 KEY 是什么？是用户 ID 还是用户名？
我在单独的expolrer 中打开了表，并注意到Membership 数据库中的UserID 与应用程序Roles 数据库中的UserID 不同。
I have an ASP.NET project where I want to keep the membership (SQL Provider) in a separate database and the Roles/Profiles will be per application.
Question
What is the KEY that relates between the Membership database and the Roles/Profile database? Is it the UserID or UserName?
I opened up the tables in separate expolrer and notice the UserID is different in the Membership database from that in the application Roles database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果我正确地阅读了您的问题，您希望将成员资格存储在一个数据库实例中，并将角色存储在另一个数据库实例中。
这是可以接受的，并且可以通过简单地提供不同的连接字符串来实现。您不需要不需要实现自定义提供程序。
了解角色和成员资格确实是独立的问题（除了 MembershipProvider.DeleteUser 方法造成的轻微出血），并且可以单独操作。
角色和成员资格表之间不存在真正的“关系”，并且通过 aspnet_users 表中记录的出现推断出的任何关系都是巧合的。如果在对用户进行角色查询时存在记录，则使用该 userId，否则将创建具有新 userId 的新记录。
整个提供程序堆栈中使用的通用值是用户名字段，虽然该字段对于应用程序来说是唯一的，但它不是键。
因此，只要您意识到调用 Membership.DeleteUser 时必须手动执行角色记录的删除，您就可以简单地使用两个数据库，无需自定义实现。
祝你好运
If I read your question correctly, you wish to store membership in one database instance and roles in another.
This is acceptable and possible by simply providing different connection strings. You no not need to implement a custom provider.
Understanding the fact that roles and membership are truly separate concerns, except for minor bleeding posed by the MembershipProvider.DeleteUser method, and can operate in isolation.
There is no true 'relation' between the roles and membership tables and any that are inferred by the appearance of records in the aspnet_users table are coincidental. If a record is present when a role query is made for a user, that userId is used otherwise a new record with a new userId is created.
The common value used throughout the provider stack is the
usernamefield, which, while unique to an application, is not a key.So, as long as you are aware that you must manually perform deletion of role records when you call Membership.DeleteUser, you may simply use two databases, no custom implementation required.
Good luck
在这种情况下，您能做的最好的事情就是实现您自己的（自定义）MemberShip 和 Role 提供程序。成员资格和角色之间的关系由您自己定义，通常使用用户名。
对诗人回应的评论：
也许我不应该提到“最佳解决方案”，但在我看来，默认的 AspNet 成员资格和角色提供程序伴随着使用 aspnet -regsql 命令创建的 Aspnet 表。如果 Microsoft 的会员资格和角色提供程序不能满足您的需求，您应该创建自己的会员资格和角色提供程序。
如果您创建自己的成员资格和角色提供程序，其他开发人员会清楚地知道他们正在处理以不同方式工作或构建的提供程序实现。
我的结论是，我的解决方案可能不是“最佳解决方案”，而更多的是建议。另一件事是 ASP.NET 提供程序无论如何都不是良好软件设计的示例。我们仍在使用它，因为它们与其他控件兼容。你的解决方案没问题，但我的也可以，这取决于先生。 Saif 选择最适合其应用的解决方案。
正如 Microsoft 提到的：
创建自定义成员资格提供程序有两个主要原因。
您需要将成员资格信息存储在 .NET Framework 中包含的成员资格提供程序不支持的数据源中，例如作为 FoxPro 数据库、Oracle 数据库或其他数据源。
•您需要使用以下方式管理会员信息
The best thing you can do in this case is implementing your own (custom) MemberShip and Role provider. The relationship between a membership and roles are defined by yourself and the username is commonly used for this.
Remark on Poet's responses:
Perhaps i shouldn't have mentioned "best solution", but in my opinion the default AspNet membership and Role provider accompanies the Aspnet tables which are created using the aspnet -regsql command. If Microsoft's Membership and Role Provider don't fullfil your needs, you should create your own.
If you create your own membership and role provider, it will be clear to other developers that they are dealing with a provider implementation which works or is structured in a different way.
My conclusion is that my solution was perhaps not "the best solution", but more a recommendation. The other thing is that the ASP.NET Providers aren't an example of good software design anyway. We are still using it, because of their compatibility with other controls. Your solution is ok, but mine will do as well and it's up to mr. Saif to choose a solution that fits best in his application.
As Microsoft mentions:
There are two primary reasons for creating a custom membership provider.
•You need to store membership information in a data source that is not supported by the membership providers included with the .NET Framework, such as a FoxPro database, an Oracle database, or other data source.
•You need to manage membership information using a