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