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

Question

不久前，我浏览了一个自定义个人资料提供商示例，现在正在重新审视它。

当我运行ASPNET注册向导时，我的数据库具有创建的所有DBO.ASPNET_*。在这些表中，我有 aspnet_Profile，它有一个指向 aspnet_Users 的 FK 约束。

我在 MyDB 中还有两个表：第一个，dbo.profiledata，具有指向DBO.Profile的外键约束。

我想了解的是MyDB中的表与dbo.aspnet_*中的表如何相关。MYDB和ASPNET表中的配置文件表之间是否应该存在外键约束（或某种关系）？关于我的自定义表与Aspnet提供的定制表如何相关的一些讨论将是很棒的。

提前致谢。

Answer 1

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

• 远从 dbo.aspnet_User.UserID 到 dbo.Profile.UserID, ，然后定义一个唯一的键 dbo.Profile.UserID （除非你用它作为 PK 列 dbo.Profile)

• 远从 dbo.aspnet_Profile.ProfileID 到 dbo.Profile.ProfileID

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

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

编辑

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

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

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

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

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

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