asp.net 会员数据库。为用户添加分支
我正在研究会员数据库并有一个问题。假设我有一家名为 ABC 公司的公司。 ABC公司旗下有10家分公司。
无论如何，是否可以使用公司 ABC 作为父级并以 10 个分支机构作为子级在数据库中创建关系？
我希望这是有道理的:)
I am playing around with the membership database and have a question. Lets say I have a company called company ABC. There are 10 branches that belong to comapany ABC.
IS there anyway to create a relationship within the database using company ABC as the parent and having the 10 branches as childs?
I hope that makes sense :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以扩展会员数据库并编写自己的提供程序等
看这里
然而，这是一个很大的痛苦，如果我明白你的意思，那就是浪费精力。
我是否正确地认为您希望将会员数据库中的用户链接到您自己的数据中使用，因此想添加额外的表（公司、分支机构、用户）等？
如果是这样，只需使用您的自定义表滚动第二个数据库即可。在您自己的数据库的用户表中存储唯一的会员用户名，并使用它链接到您的业务逻辑中的两个。
例如，如果您需要获取分支 X 中每个用户的成员角色。
a)从自定义数据库中获取分支 X 中的所有用户
b) 迭代它们，使用对 Membership 的调用来获取用户及其角色。
或者，对于当前登录的用户获取他们的公司。获取当前登录的用户名，使用它从数据库中获取用户并获取他们的分支机构和公司等。
我知道两个糟糕的例子，但希望有所帮助。
TL;DR 使用您自己的数据库和会员数据库，并将每个用户的会员用户名也存储在您的数据库中。在大多数情况下，将两者合并并不值得这么麻烦。
You can extend the membership database and write your own provider etc
look here
However that is a big pain, and if i understand what your after then a waste of effort.
Am I right in thinking you want to link users in the membership database to uses within your own data, and therefore would like to add extra tables (company, branch, user) etc?
If so, just roll a second database with your custom tables. In the user table of your own database store the unique membership username and use this to link to the two in your buisness logic.
Eg, if you need to get the membership roles for every user in Branch X.
a)Get all users in Branch X from your custom database
b)Iterate over them all, using a call to Membership to get the user and their roles.
Or, for the current logged in user get their company. Get the current logged in username, use that to get the user from your DB and get their branch and company etc.
Two poor examples, i know, but hope that helps.
TL;DR use your own database alongside the membership one, storing the membership username of each user in your database too. Merging the two isnt worth the hassle in most cases.