合并两个 ASP.NET 成员数据库
我必须将两个 ASP.NET 成员资格数据库与相关的角色和配置文件表合并。两个数据库具有相同的角色和配置文件结构。他们使用内置的提供程序(SqlMembershipProvider 和朋友)。重复是可能的。
你有什么建议给我吗?有没有工具可以做到这一点?如果没有:您能否推荐使用会员资格 API,或者使用 SQL 是否更容易。
更新
这是我最终用来传输会员数据的脚本。
insert into targetMembershipDatabase.dbo.aspnet_users
select * from sourceMembershipDatabase.dbo.aspnet_users
where username not in (select username from targetMembershipDatabase.dbo.aspnet_users)
insert into targetMembershipDatabase.dbo.aspnet_membership
select * from sourceMembershipDatabase.dbo.aspnet_membership
where userid in (select userid from targetMembershipDatabase.dbo.aspnet_users)
and not userid in (select userid from targetMembershipDatabase.dbo.aspnet_membership)
insert into targetMembershipDatabase.dbo.aspnet_profile
select * from sourceMembershipDatabase.dbo.aspnet_profile
where userid in (select userid from targetMembershipDatabase.dbo.aspnet_users)
and not userid in (select userid from targetMembershipDatabase.dbo.aspnet_profile)
insert into targetMembershipDatabase.dbo.aspnet_usersinroles
select * from sourceMembershipDatabase.dbo.aspnet_usersinroles
where userid in (select userid from targetMembershipDatabase.dbo.aspnet_users)
and not userid in (select userid from targetMembershipDatabase.dbo.aspnet_usersinroles)
按原样提供。不检查重复的电子邮件。不保证这在更复杂的场景中有效。
I have to merge two ASP.NET membership databases with related role and profile tables. Both databases have an identical role and profile structure. They use the built in providers (SqlMembershipProvider and friends). Duplicates are possible.
Do you have recommendations for me? Is there a tool to do this? If not: Can you recommend using the membership API or is it easier to use SQL.
Update
Here is the script I finally used to transfer the membership data.
insert into targetMembershipDatabase.dbo.aspnet_users
select * from sourceMembershipDatabase.dbo.aspnet_users
where username not in (select username from targetMembershipDatabase.dbo.aspnet_users)
insert into targetMembershipDatabase.dbo.aspnet_membership
select * from sourceMembershipDatabase.dbo.aspnet_membership
where userid in (select userid from targetMembershipDatabase.dbo.aspnet_users)
and not userid in (select userid from targetMembershipDatabase.dbo.aspnet_membership)
insert into targetMembershipDatabase.dbo.aspnet_profile
select * from sourceMembershipDatabase.dbo.aspnet_profile
where userid in (select userid from targetMembershipDatabase.dbo.aspnet_users)
and not userid in (select userid from targetMembershipDatabase.dbo.aspnet_profile)
insert into targetMembershipDatabase.dbo.aspnet_usersinroles
select * from sourceMembershipDatabase.dbo.aspnet_usersinroles
where userid in (select userid from targetMembershipDatabase.dbo.aspnet_users)
and not userid in (select userid from targetMembershipDatabase.dbo.aspnet_usersinroles)
Provided as is. No check for duplicate emails. No warranty that this is working in a more complex scenario.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我不知道有任何工具可以做到这一点,但架构非常简单,因此只需在 SQL 中完成它就足够简单了。无论如何,所有的键都是 GUID,所以应该没有问题。
显然,如果应用了唯一电子邮件地址规则,您需要检查 user_name 字段是否有重复项和电子邮件地址。但是,如果两个数据库中的角色相同,那么您真正感兴趣的是用户。一旦您完成了它们,只需更新
aspnet_Users
和aspnet_UsersInRoles
中的RoleId
和ApplicationId
即可>。I not aware of any tool which will do this, but the schema is pretty simple so it would be a straightforward enough job to just do it in SQL. All the keys are GUID anyway, so there shouldn't be a problem.
Obviously you'd need to check the user_name field for duplicates and email addresses, if the unique email address rule is applied. But if the roles are the same in both databases then all you're really interested in are the users. Once you've got them over it would just be a case of updating the
RoleId
andApplicationId
inaspnet_Users
andaspnet_UsersInRoles
.我目前对三个不同的应用程序使用一个数据库。他们每个人都有自己的
ApplicationID
,在这两年里我没有发生什么特别的事情。甚至类似的邮件也是可用的(因为sql检查ApplicationID
并且在每个应用程序中只有一封邮件)所以我认为你不必考虑一些特殊的事情只需从数据创建一个脚本并运行您的 mainDatabase 只是不替换表的架构。
I am currently use a single database for three different applications. Each of them has its own
ApplicationID
and nothing special happend for me withing this 2 years. even similar mails are available (because sql check theApplicationID
and in each application only you have one mail) so I don't think that you have to consider something specialJust create a script from data and run in your mainDatabase just not that don't replace the schema of Tables.