用户和人-在哪里保存电子邮件地址？

Question

我正在设计一个类似于Facebook的应用程序，叫做Headtome。我希望有创建公共配置文件的用户，包括电子邮件地址。然后，玛丽可以选择给约翰发短信，这条信息直接传到他公开的电子邮件上。更令人毛骨悚然的是，如果约翰和玛丽在一段关系中标榜自己，那么只有约翰才能看到玛丽的个人资料。

以下是当前数据库结构的一部分：

表users：

id | username | password | person_id |
--------------------------------------

表persons：

id | first_name | last_name | nickname |
----------------------------------------

表person_emails：

id | person_id | email_address | is_main |
------------------------------------------

我使用一个单独的表格来处理电子邮件，因为一个人可能会决定显示多个电子邮件地址。

我认为users表也应该有一个email_address列。

The Pros

• 如果用户忘记了密码，我们需要一个电子邮件地址来重置它。
• 用户可能使用与他们在配置文件上显示的邮件不同的电子邮件登录。
• 或者，他们可能会选择根本不显示电子邮件(不要给我发短信)
• 用户的配置文件数据仍然可用(通过person_id)
• 用户电子邮件可能是永久的，而公共邮件则是临时的(与工作有关，等等)。
• 玛丽给约翰发短信时，她是在给约翰发短信，而不是给用户约翰发短信

The Cons

• 管理两个单独的电子邮件地址可能会使用户感到困惑。
• 或者它可能导致重复
• 重点是创建一个概要文件，所以persons是主表
• 如果约翰和玛丽在约会，难道不是用户约翰被允许看她的个人资料吗？

这里的正确方法是什么？这并不是说它会有什么不同，但这是在MySQL中。此外，这也是一个虚构的例子，说明了一个真正的困境。

Answer 1

我会创建一个不同的电子邮件表，并使用代理键实例化电子邮件地址对个人和用户的引用。模型将如下所示：

这处理了将电子邮件地址与用户和人员相关联的需要，但消除了使用实际的电子邮件地址文本实例化关系的冗余。它还有一个额外的好处，即确保您了解谁实际使用的是给定的电子邮件地址，因为您可以在电子邮件地址文本上放置另一个唯一的索引，作为指定的电子邮件地址。我认为这种解决办法可以消除缺点，同时保留所有的优点。

Answer 2

不需要有一个表用户和另一个表用户。我从来没有见过允许一个用户创建多个配置文件的社交网络。的确，有些人保存了多个配置文件，但这是通过打开多个帐户来完成的(有时是针对TOS的)。

您可以使用此模型：

Table users:
user_id (PK)
username (IDX, unique)
firstname
lastname
password 
date_of_birth
(... other personal data ...)

Table user_emails:
email_id (PK)
user_id (FK)
email_address  
is_main 

用户将通过用户名和主电子邮件地址登录到网站(user_emails.is_main = TRUE)。

Answer 3

我先做个假设。一个真实世界的人在你的系统中可能有不止一个用户？如果一个真实世界的人(人员表)可以(而且应该)只有一个用户，你为什么允许这两个表之间有一个到多个关系？或者我误解了你的模型，或者我会在逻辑数据模型中为用户和个人创建一个表，其中包含与该人相关的所有信息，包括电子邮件地址。如果您想存储两个不同的电子邮件地址，您可以使用两个不同的列，只要您不打算存储无限数量的电子邮件地址(就像在网上商店中与您的配置文件相关联的传递地址一样)。我将使用一个user_login NULL列(您称之为John，它必须是注册时用于验证的电子邮件地址)和另一个列email_contact (您称之为John )，还有一个额外的标志，以供联系或不联系。无论如何，您可能希望验证这第二封电子邮件以及。

除此之外，您还可以为日期维护一个person_to_person关系表，并使用它作为一个指示器来控制某个人是否公开可用，并在应用程序层中显示它的概要文件。