使用 ASP.NET SQL 成员资格提供程序，如何存储我自己的每用户数据？

我正在使用 ASP.NET SQL 成员资格提供程序。所以，有一个aspnet_Users表包含我的每个用户的详细信息。 （实际上，aspnet_Membership表似乎包含大部分实际数据）。

我现在想在数据库中存储一些每个用户的信息，所以我想我只需创建一个带有UserId(GUID) 列和 FK 关系aspnet_Users。然而，我后来发现我无法轻松访问UserId因为它不是通过会员 API 公开的。 （我知道我可以通过ProviderUserKey，但 API 似乎正在抽象掉内部UserID赞成UserName，而且我不想太过违背原则）。

所以，我想我应该放一个LoweredUserName我的表中的列，并创建一个 FK 关系aspnet_Users使用那个。嗡嗡声。又错了，因为虽然有一个唯一索引aspnet_Users that includes the LoweredUserName，它还包括ApplicationId- 所以为了建立我的 FK 关系，我需要有一个ApplicationId我的表中也有列。

起初我想：好吧，我只处理一个应用程序，所以我只需添加这样一个列并给它一个默认值。然后我意识到ApplicationId是一个GUID，所以这样做会很痛苦。不是hard确实如此，但在我推出我的数据库之前，我无法预测 GUID 将会是什么。

我觉得我错过了一些东西，或者以错误的方式处理事情。我是什么supposed to do?

我认为您正在寻找 ProfileProvider，它可以让您将您想要的任何任意信息与用户相关联。

ASP.NET 配置文件属性概述 http://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx

ADDITION如果内置的 ProfileProvider 不能满足您的需求，那么您可以考虑通过编写一个派生自的类来实现您自己的 ProfileProviderSystem.Web.Profile.ProfileProvider。这将使您能够编写一些避免您在评论中提到的序列化问题的内容。

实施配置文件提供程序 http://msdn.microsoft.com/en-us/library/0580x1f5%28VS.80%29.aspx

ADDITION有关 SqlMembershipProvider 的注意事项。您确实是正确的，即使架构是在 UserId 上键入的，但会员资格类实际上是在用户名上键入的。坦率地说，这是我对 SqlMembershipProvider 类最讨厌的事情之一。这实际上会在多应用程序环境中产生问题，在该环境中您需要单个用户存储但需要独立的应用程序角色列表。

我的建议是在 UserId 上键入键，因为正如您所提到的，它是 aspnet_Users 表的主键，并且在所有外键关系中使用，并且它是单个值。如果您键入 LowerUsername（和 ApplicationId），并且用户名发生更改，则需要启用级联更新，以便更改会波及到您的自定义表。