无论您在何处存储aspnetdb表(在单独的数据库中或与数据存储在同一数据库中),问题仍然存在于如何保持数据同步.
经过研究,我看到以下相关选项：
1.来自asp_Users的外键UserId(在this教程中建议).
2.没有外键 – 使用交易(建议here).
3.没有外键 – 使用自定义的AccountController(无论是什么,建议here).
4.将Membership UserId(uid)与自定义UserId(int)相链接的附加表.
5. …
一方面,我喜欢第一个解决方案,因为它非常简单,并在官方的asp.net教程中提出.
另一方面,反对者非常合理地指出,使用外键打破了提供者的一般想法,这些提供者应该帮助分离关注点并且可以互换.但不幸的是,他们并没有深入了解实施细节,因此从相关性和易于实施的角度来估计这些建议并不容易.
那么解决这个问题的最佳选择是什么？此外,实现将如何？仅仅使用额外的ADO.NET或LINQ等代码是否足够,还是值得实现自定义成员资格和/或配置文件提供程序？
先感谢您.
解决方法
我在当前的应用程序中成功使用了选项4.我创建了一个表aspnet_UserID,其中idUser int作为主键,fiUser(aspnet_Users的GUID)作为外键.这是模型：
(注意：User是通过aspnet_regsql.exe创建的标准aspnet_Users表,aspnet_UserId是我的自定义表,它将每个Guid映射到我的int-ID)
现在我只在所有相关表中存储我的idUser作为FK(如在Order-Table中).这样做的好处是存储空间更小,UserID更易读(我永远不会记住GUID).也许它与这个“包装表”有点分离,但这不是我的主要意图.
如果要控制行为,可以更改外键上的delete-rule.如果你是f.e.将它设置为Cascade.想删除您要删除的用户订购的所有订单,或者如果要保留此订单,则将其设置为无操作.
我不能为配置文件问题提出任何替代方案,因为您没有提到“您需要以更灵活的方式存储和访问用户配置文件数据,而不是配置文件提供程序支持”.
