MVC 5，想要将电子邮件地址添加到用户配置文件，我应该添加到哪个 table？用户配置文件或 webpages_membership？ （数据库设计）
MVC 5, want to add email address to userprofile, which table should I add to? userprofile or webpages_membership? (database design)
我有一个新的 MVC5 网络应用程序，目前，默认情况下，
table: 用户资料
存储用户名和用户 ID。
CREATE TABLE [dbo].[UserProfile] (
[UserId] INT IDENTITY (1, 1) NOT NULL,
[UserName] NVARCHAR (MAX) NULL,
[FirstName] VARCHAR (MAX) NULL,
[LastName] VARCHAR (MAX) NULL,
PRIMARY KEY CLUSTERED ([UserId] ASC)
);
table: webpages_membership 存储用户密码。
CREATE TABLE [dbo].[webpages_Membership] (
[UserId] INT NOT NULL,
[CreateDate] DATETIME NULL,
[ConfirmationToken] NVARCHAR (128) NULL,
[IsConfirmed] BIT DEFAULT ((0)) NULL,
[LastPasswordFailureDate] DATETIME NULL,
[PasswordFailuresSinceLastSuccess] INT DEFAULT ((0)) NOT NULL,
[Password] NVARCHAR (128) NOT NULL,
[PasswordChangedDate] DATETIME NULL,
[PasswordSalt] NVARCHAR (128) NOT NULL,
[PasswordVerificationToken] NVARCHAR (128) NULL,
[PasswordVerificationTokenExpirationDate] DATETIME NULL,
PRIMARY KEY CLUSTERED ([UserId] ASC)
);
我想将 emailaddress 和 emailaddressConfirmed 添加到 table。我应该添加哪一个？或者构建一个包含所有内容的 table？
另外，我对会员和角色一无所知，我是否应该花时间了解一下？ （还是只对深奥的东西有用？）
这在很大程度上取决于用例基础，但一般来说，最好将其添加到 UserProfile table。
如果您希望用户对 his/her 电子邮件地址进行 CRUD，出于各种原因，最好将电子邮件字段存储在 UserProfile table 中。
- 尽量减少数据库调用。在单个 table 中存储他具有（可能不同级别的）CRUD 访问权限的用户的所有属性允许您在 Fetching/Updating 特定用户的数据时访问您的数据库一次。
- 模特优雅。与上面略有不同，访问一个 table 用于您将添加到模型（and/or 视图模型）的所有属性传递给您的视图，您的代码（C# 或存储过程中的 SQL ，取决于你放置逻辑的位置）会更优雅，更容易阅读，避免 JOIN 等。
还有很多其他原因，其中很多我都没有完全理解，但这两个是最重要的，最大限度地减少调用和代码清洁。反对的理由也有：
- 受保护的信息。您是否在您的设置中考虑电子邮件敏感信息？在您的域中是否有关于此信息的法律（例如：一些美国学校的电子邮件通过 FERPA 受到保护）？受保护的信息可能需要更改权限，以不安全的方式存储它们或不及时地显示它们会使您处于合法范围内。
同样，各种用例和您的特定项目可能需要不同的设计，较小的独立项目可能需要一种设计，而大型企业项目可能需要更精简的设计，并且可能担心落入某些法律范围。
至于 memberships/roles，它们在企业级数据库设置中当然很有用，其中可能需要权限，但 'should you invest time' 太主观了，无法真正回答。
我有一个新的 MVC5 网络应用程序，目前，默认情况下， table: 用户资料 存储用户名和用户 ID。
CREATE TABLE [dbo].[UserProfile] (
[UserId] INT IDENTITY (1, 1) NOT NULL,
[UserName] NVARCHAR (MAX) NULL,
[FirstName] VARCHAR (MAX) NULL,
[LastName] VARCHAR (MAX) NULL,
PRIMARY KEY CLUSTERED ([UserId] ASC)
);
table: webpages_membership 存储用户密码。
CREATE TABLE [dbo].[webpages_Membership] (
[UserId] INT NOT NULL,
[CreateDate] DATETIME NULL,
[ConfirmationToken] NVARCHAR (128) NULL,
[IsConfirmed] BIT DEFAULT ((0)) NULL,
[LastPasswordFailureDate] DATETIME NULL,
[PasswordFailuresSinceLastSuccess] INT DEFAULT ((0)) NOT NULL,
[Password] NVARCHAR (128) NOT NULL,
[PasswordChangedDate] DATETIME NULL,
[PasswordSalt] NVARCHAR (128) NOT NULL,
[PasswordVerificationToken] NVARCHAR (128) NULL,
[PasswordVerificationTokenExpirationDate] DATETIME NULL,
PRIMARY KEY CLUSTERED ([UserId] ASC)
);
我想将 emailaddress 和 emailaddressConfirmed 添加到 table。我应该添加哪一个？或者构建一个包含所有内容的 table？
另外，我对会员和角色一无所知，我是否应该花时间了解一下？ （还是只对深奥的东西有用？）
这在很大程度上取决于用例基础，但一般来说，最好将其添加到 UserProfile table。
如果您希望用户对 his/her 电子邮件地址进行 CRUD，出于各种原因，最好将电子邮件字段存储在 UserProfile table 中。
- 尽量减少数据库调用。在单个 table 中存储他具有（可能不同级别的）CRUD 访问权限的用户的所有属性允许您在 Fetching/Updating 特定用户的数据时访问您的数据库一次。
- 模特优雅。与上面略有不同，访问一个 table 用于您将添加到模型（and/or 视图模型）的所有属性传递给您的视图，您的代码（C# 或存储过程中的 SQL ，取决于你放置逻辑的位置）会更优雅，更容易阅读，避免 JOIN 等。
还有很多其他原因，其中很多我都没有完全理解，但这两个是最重要的，最大限度地减少调用和代码清洁。反对的理由也有：
- 受保护的信息。您是否在您的设置中考虑电子邮件敏感信息？在您的域中是否有关于此信息的法律（例如：一些美国学校的电子邮件通过 FERPA 受到保护）？受保护的信息可能需要更改权限，以不安全的方式存储它们或不及时地显示它们会使您处于合法范围内。
同样，各种用例和您的特定项目可能需要不同的设计，较小的独立项目可能需要一种设计，而大型企业项目可能需要更精简的设计，并且可能担心落入某些法律范围。
至于 memberships/roles，它们在企业级数据库设置中当然很有用，其中可能需要权限，但 'should you invest time' 太主观了，无法真正回答。