用于联系详细信息的 sql 数据库模型答案

【问题标题】：sql database model for contact details用于联系详细信息的 sql 数据库模型
【发布时间】：2011-01-08 19:25:55
【问题描述】：

我需要一个数据库来存储，即用户记录。常规资料：姓名、电子邮件、地址、电话、传真等。问题是，在这种情况下，每个用户可能有多个电话号码。而且不止一封电子邮件。甚至不止一个地址。还有更多不止一个的东西。

一种方法是将所有内容存储在一个表中，例如一个电话列中的序列化电话数组。或在一个电话列中以逗号分隔电话。但我真的不喜欢这种方式，我宁愿做过于复杂的数据库，让编程逻辑更简单，而不是反过来。

另一种是电话单独表、地址单独表等。列：id、customer_id、电话。 customer_id references customers.id 现在这似乎有点矫枉过正，大约 10 个表仅用于存储联系方式.

我想出的另一个想法是为联系人添加一个表格，其中包含 id、customer_id（key 等列>、价值。其中键可以是“电话”和值“+123 3435454”，或者键可以是“电子邮件”和值......你明白了。到目前为止，我最喜欢这个。

你有什么建议？ #3 方法的缺点是什么？

我要使用的db是postgresql，但这并不重要。

【问题讨论】：

【解决方案1】：

有些人可能会说方法#3 是最好的。其他人会说它基本上是数据库中最常见的反模式之一 - 即EAV，它得到了很多仇恨。

至于我 - 我对您的应用程序知之甚少，无法提出解决方案。通常 - 方法 #2 为您提供最多的功能。

还有方法 #4，它的变体 - 方法 #5：

4 - 使用值数组 - 即电话列，而不是 TEXT 数据库，是 TEXT[]，然后您可以在其中存储许多电话。

5 - 因为你在 PostgreSQL 上 - 使用它。 contrib 中有一个非常酷的 hstore 数据类型，您可以使用它代替数组来添加一些语义（如电话类型）。

【讨论】：

【解决方案2】：

一些纯粹主义者会建议不要选择 3。事实上，使用这种方法理论上你可以构建一个单表数据库！

但是，就像 gbn 提到的那样，这会导致特定格式出现问题，并且您必须仅在客户端上强制执行数据长度等。

我会接受您的第二个建议，并使用具有不同表格的方法，其地址类型、电话号码类型等类似于如下所示。

身份证号码 addrss_type varchar（家庭/联系人/邮件等） addrs_line1 varchar addrs_line2 varchar 等等等等

【讨论】：

【解决方案3】：

每个实体一个表行是正确的。所以一个用于电子邮件，一个用于电话号码等是正确的。这不是矫枉过正：它是标准化的数据库设计。

您的选项 3 可以完成，但是，如果您想对电话号码和电子邮件地址强制执行某种模式怎么办？

【讨论】：

【解决方案4】：

缺点：

这违反了第一范式，因为一个字段会有多个值
正如您所说，维护这将是一场噩梦
似乎是下注选项，但可以通过使用域表来规范该“关键”值
- Customer (Id, Name)
- AdditionalData( Id, Name )（电话、地址等）
- CustomerAdditionalData(Id, CustomerId, AdditionalDataId, Value)

【讨论】：