当使用独立数据库作为成员资格提供程序时，通常在数据库中为应用程序提供特定于应用程序的用户表吗？ 例如，假设我有一个管理用户消息的应用程序。通常我会有一个user_messages表并引用users表外键？但是，如果我只是在成员资格数据库中使用id，则我无法通过外键引用用户的消息。
任何指针都非常赞赏
答案 0 :(得分：1)
“如果我只是在中使用id 会员db我不能参考 用户通过外键“
发送的消息
这里的问题是执行外键。我不知道任何DBMS支持跨数据库链接引用表的外键。即使它可能是可取的吗？这样的安排意味着如果远程数据库因任何原因离线，我们就无法在本地数据库中插入子记录。
此类方案中的正常解决方法是复制，即在本地数据库中维护远程表的副本。如果我们有一个支持远程物化视图的DBMS，那么这可能是一个非常简单的实现。
答案 1 :(得分：1)
我也对此感兴趣。这可能不符合答案 - 但是一旦我实施，我就会更新。
我也在使用我的网络应用程序的ASP.NET成员资格提供程序;虽然我已经在我的数据库中包含了SQL表和Procs for Membership Provider，但我保持了逻辑分离，所以你可以单独运行它。如果你也愿意的话。
虽然你已经集中在这里的数据库问题（这是公平的），但重要的是要记住，使用ASP.NET成员资格提供程序，您不仅仅需要处理数据库。关于ASP.NET成员资格提供程序的事情是提供程序本身 - 实际的数据存储库是抽象出来的。
我假设使用ASP.NET成员资格提供程序，我将能够使用提供程序本身的服务/ API来帮助管理您正在谈论的关系。所以我不会特别依赖数据库 - 因为“提供者”是我应该经历的外部接口，使用它会把我绑定到那个数据源。