我前一段时间经历了一个自定义配置文件提供程序示例 现在重新审视它。
我运行aspnet注册时创建了所有dbo.aspnet_ *表 向导。在这些表中，我有aspnet_Profile，它有一个指向aspnet_Users的FK约束。
我在MyDB中也有两个表：第一个是dbo.ProfileData，它有一个外键约束 指向dbo.Profile。
我想了解的是MyDB中的表格如何与之相关 那些在dbo.aspnet_ *。不应该有外键约束（或某种类型的 MyDB中的配置文件表和aspnet表之间的关系？一些讨论 我的自定义表如何与aspnet提供的表相关将是非常好的。
提前致谢。
答案 0 :(得分：1)
我可以看到两个选项，两者都会产生基本相同的结果：
FK从dbo.aspnet_User.UserID到dbo.Profile.UserID，然后在dbo.Profile.UserID上定义唯一键（除非您将其用作dbo.Profile的PK列）
FK从dbo.aspnet_Profile.ProfileID到dbo.Profile.ProfileID
dbo.aspnet_User在逻辑上是1 - 1，dbo.aspnet_Profile，因此您使用哪种方法并不重要，因为您仍然可以获得相同的关系完整性。
如果要用自己的实现替换标准配置文件数据表，则使用第一个建议更有意义，否则如果要扩展Profile模式，则使用第二个建议。
修改
aspnet_Profile是标准表 - 标准SqlProfileProvider将用户的个人资料数据存储为aspnet_Profile中的序列化属性包，因此没有单独的aspnet_ProfileData表作为好。
此方法允许为不同的应用程序轻松自定义配置文件架构，而无需对底层数据库进行任何更改，并且是.NET等框架的最佳解决方案。缺点是SQL Server根本无法轻松访问这些数据，因此使用T-SQL和基于集合的逻辑索引，更新和查询用户的配置文件数据要困难得多。
我看到删除此限制的最常见方法是扩展标准SqlProfileProvider以写入自定义配置文件数据表，该数据表具有特定于应用程序的配置文件属性的特定列。该表自然与aspnet_Profile表有1-1关系，因此它具有如上所示的外键。
扩展提供程序的作用是在配置文件写入期间将特定的配置文件属性提升为列，并在检索配置文件时读取列。
这允许您根据需要混合搭配存储解决方案，只要您的扩展提供商知道如何回退到它不知道给定属性的标准实现。
我一直认为最好保留标准成员资格表，并在必要时使用具有适当外键的新表进行扩展，然后继承适当的提供程序并使用您自己的实现覆盖提供程序方法（调用基础尽可能实施。