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