3

前段时间我浏览了一个自定义配置文件提供程序示例，现在我正在重新访问它。

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

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

我想了解的是 MyDB 中的表与 dbo.aspnet_* 中的表之间的关系。MyDB 中的配置文件表和 aspnet 表之间不应该存在外键约束（或某种关系）吗？关于我的自定义表格与 aspnet 提供的表格之间的关系的一些讨论会很棒。

提前致谢。

4

1 回答 1

1

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

  • FK 从dbo.aspnet_User.UserID到dbo.Profile.UserID，然后在上定义一个唯一键dbo.Profile.UserID（除非您将其用作 PK 列dbo.Profile）

  • 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的关系，所以它有一个如上所示的外键。

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

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

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

于 2009-12-02T00:16:57.623 回答