ASPNET成员资格提供程序表和自定义成员资格表之间的关系 [英] Relationship Between ASPNET Membership Provider Tables and Custom Membership Tables

问题描述

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

I went through a custom profile provider example a while ago and I am now revisiting it.

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

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.

我在MyDB中也有两个表:第一个表dbo.ProfileData具有外键约束 指向dbo.Profile.

I also have two tables in MyDB: The first, dbo.ProfileData, has a foreign key constraint pointing to dbo.Profile.

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

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.

先谢谢了.

推荐答案

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

There are two options I can see, both of which will yield basically the same result:

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

• FK from dbo.aspnet_User.UserID to dbo.Profile.UserID, then define a unique key on dbo.Profile.UserID (unless you use it as the PK column for dbo.Profile)

FK从dbo.aspnet_Profile.ProfileID到dbo.Profile.ProfileID

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

dbo.aspnet_User is logically 1 - 1 with dbo.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.

编辑

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

aspnet_Profile is the standard table - the standard SqlProfileProvider stores the user's profile data as a serialized property bag in aspnet_Profile, hence why there is no separate aspnet_ProfileData table as well.

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

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.

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

The most common approach I have seen to remove this limitation is to extend the standard SqlProfileProvider to 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).

这篇关于ASPNET成员资格提供程序表和自定义成员资格表之间的关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！