ASPNET 成员资格提供程序表和自定义成员资格表之间的关系

我不久前经历了一个自定义配置文件提供程序示例，我是 现在重新审视它。

我的数据库包含运行 aspnet 注册时创建的所有 dbo.aspnet_* 表 向导。在这些表中，我有 aspnet_Profile，它有一个指向 aspnet_Users 的 FK 约束。

我在 MyDB 中还有两个表：第一个表 dbo.ProfileData 有外键约束 指向 dbo.Profile。

我想了解的是 MyDB 中的表如何关联 dbo.aspnet_* 中的那些。不应该有外键约束（或某种 MyDB 中的配置文件表和 aspnet 表之间的关系）？一些讨论 我的自定义表格与 aspnet 提供的表格之间的关系将是非常棒的。

提前致谢。

我可以看到两个选项，这两个选项都会产生基本相同的结果：

• FK from dbo.aspnet_User.UserID to dbo.Profile.UserID，然后定义一个唯一的键dbo.Profile.UserID（除非你用它作为 PK 列dbo.Profile)

• FK from dbo.aspnet_Profile.ProfileID to dbo.Profile.ProfileID

dbo.aspnet_User逻辑上是 1 - 1dbo.aspnet_Profile，因此使用哪种方法并不重要，因为您仍然可以获得相同的关系完整性。

如果您要使用自己的实现替换标准配置文件数据表，则使用第一个建议更有意义，否则，如果您要扩展配置文件架构，则使用第二个建议。

EDIT

aspnet_Profile是标准表-标准SqlProfileProvider将用户的个人资料数据存储为序列化的属性包aspnet_Profile，因此为什么没有单独的aspnet_ProfileData表也​​是如此。

这种方法允许轻松地为不同的应用程序定制配置文件模式，而不需要对底层数据库进行任何更改，并且是 .NET 等框架的最佳解决方案。缺点是 SQL Server 根本无法轻松访问这些数据，因此使用 T-SQL 和基于集合的逻辑索引、更新和查询用户的个人资料数据要困难得多。

我见过的消除此限制的最常见方法是扩展标准SqlProfileProvider写入自定义配置文件数据表，该表具有用于特定于应用程序的配置文件属性的特定列。该表自然与 aspnet_Profile 表具有 1-1 关系，因此它具有如上所示的外键。

扩展提供程序的作用是在配置文件写入期间将特定配置文件属性提升到列，并在检索配置文件时在列中读取。

这允许您根据需要混合搭配存储解决方案，只要您的扩展提供程序知道如何回退到它不“了解”给定属性的标准实现。

我始终认为最好按原样保留标准成员资格表，并在必要时使用具有适当外键的新表进行扩展，然后对适当的提供程序进行子类化并使用您自己的实现覆盖提供程序方法（尽可能调用基本实现） ）。