ASPNET 成员资格提供程序表和自定义成员资格表之间的关系
我不久前经历了一个自定义配置文件提供程序示例，我是 现在重新审视它。
我的数据库包含运行 aspnet 注册时创建的所有 dbo.aspnet_* 表 向导。在这些表中，我有 aspnet_Profile，它有一个指向 aspnet_Users 的 FK 约束。
我在 MyDB 中还有两个表：第一个表 dbo.ProfileData 有外键约束 指向 dbo.Profile。
我想了解的是 MyDB 中的表如何关联 dbo.aspnet_* 中的那些。不应该有外键约束（或某种 MyDB 中的配置文件表和 aspnet 表之间的关系）？一些讨论 我的自定义表格与 aspnet 提供的表格之间的关系将是非常棒的。
提前致谢。
I went through a custom profile provider example a while ago and I am
now revisiting it.
My database has all the dbo.aspnet_* tables created when I ran the aspnet registration
wizard. In these tables I have aspnet_Profile which has a FK constraint pointing to aspnet_Users.
I also have two tables in MyDB: The first, dbo.ProfileData, has a foreign key constraint
pointing to dbo.Profile.
What I want to understand is how the tables in MyDB relate to
those in dbo.aspnet_*. Shouldn't there be a foreign key constraint (or some kind of
relationship) between the profile tables in MyDB and the aspnet tables? Some discussion
of how my custom tables relate to those provided by aspnet would be wonderful.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我可以看到两个选项，这两个选项都会产生基本相同的结果：
FK from
dbo.aspnet_User.UserIDtodbo.Profile.UserID，然后在dbo.Profile.UserID上定义唯一键（除非您将其用作dbo.Profile的 PK 列）从
dbo.aspnet_Profile.ProfileID到dbo.Profile.ProfileIDdbo.aspnet_User与dbo.aspnet_Profile逻辑上是 1 - 1，所以它不会使用哪种方法并不重要，因为您仍然可以获得相同的关系完整性。如果您要使用自己的实现替换标准配置文件数据表，则使用第一个建议更有意义，否则，如果您要扩展配置文件架构，则使用第二个建议。
EDIT
aspnet_Profile是标准表 - 标准SqlProfileProvider将用户的配置文件数据作为序列化属性包存储在aspnet_Profile中，这就是为什么也没有单独的aspnet_ProfileData表。这种方法允许轻松地为不同的应用程序定制配置文件模式，而不需要对底层数据库进行任何更改，并且是 .NET 等框架的最佳解决方案。缺点是 SQL Server 根本无法轻松访问这些数据，因此使用 T-SQL 和基于集合的逻辑来索引、更新和查询用户的个人资料数据要困难得多。
我见过的消除此限制的最常见方法是扩展标准 SqlProfileProvider 来写入自定义配置文件数据表，该数据表具有用于特定于应用程序的配置文件属性的特定列。该表自然与 aspnet_Profile 表具有 1-1 关系，因此它具有如上所示的外键。
扩展提供程序的作用是在配置文件写入期间将特定的配置文件属性提升到列，并在检索配置文件时在列中读取。
这允许您根据需要混合搭配存储解决方案，只要您的扩展提供程序知道如何回退到它不“了解”给定属性的标准实现。
我始终认为最好按原样保留标准成员资格表，并在必要时使用具有适当外键的新表进行扩展，然后对适当的提供程序进行子类化并使用您自己的实现覆盖提供程序方法（尽可能调用基本实现） ）。
There are two options I can see, both of which will yield basically the same result:
FK from
dbo.aspnet_User.UserIDtodbo.Profile.UserID, then define a unique key ondbo.Profile.UserID(unless you use it as the PK column fordbo.Profile)FK from
dbo.aspnet_Profile.ProfileIDtodbo.Profile.ProfileIDdbo.aspnet_Useris logically 1 - 1 withdbo.aspnet_Profile, so it doesn't really matter which approach you use as you will still get the same relational integrity.If you are replacing the standard profile data table with your own implementation then it makes more sense to use the first suggestion, otherwise if you are extending the Profile schema then use the second suggestion.
EDIT
aspnet_Profileis the standard table - the standardSqlProfileProviderstores the user's profile data as a serialized property bag inaspnet_Profile, hence why there is no separateaspnet_ProfileDatatable as well.This approach allows the profile schema to be customized easily for different applications without requiring any changes to the underlying database, and is the most optimal solution for a framework such as .NET. The drawback is that SQL Server does not have easy access to this data at all, so it is much more difficult to index, update and query the user's profile data using T-SQL and set-based logic.
The most common approach I have seen to remove this limitation is to extend the standard
SqlProfileProviderto write to a custom profile data table which has specific columns for application-specific profile properties. This table naturally has a 1-1 relationship with the aspnet_Profile table, so it has a foreign key as indicated above.The role of the extended provider is to promote specific profile properties to columns during profile writes, and read in the columns when the profile is retrieved.
This allows you to mix-and-match storage solutions on an as-needs basis, as long as your extended provider knows how to fall back to the standard implementation where it does not 'know' about a given property.
I always think it is best to leave the standard membership tables as-is, and extend where necessary using new tables with appropriate foreign keys, then subclass the appropriate provider and override the provider methods with your own implementation (calling into the base implementation wherever possible).