Question

我们的数据库设计存在问题。我们必须将客户联系信息模式分解为单独的表： Phone table,Email table, Fax table等，然后我们在主many-to-many表和不同的联系表之间建立了customer关系。

例如，如果客户在不同地点工作并与其他客户共享不同位置的联系信息，则客户可以拥有多个电话号码。我正在尝试创建一个通用表来保存所有形式的联系人数据，并在contacts_types字段的查找表中使用personal, email,work email,home phone ,cell phone, work phone , home fax ,work fax,work website etc等标记值。

您建议使用哪种设计？

Answer 1

作为已完成数据库工作多年的人，请创建单独的表。首先，最终您可能需要不同的字段（我知道我们的电话表和电子邮件表具有不同的结构）。第二，您描述的模型是EAV model，它通常是性能和数据完整性的不良选择（很难强制执行您需要的所有FK）。

我永远不会使用EAV表，除非它是如此可变（如所有可能的医学测试的细节），我别无选择。

Answer 2

要设计此类数据库，您需要创建与表的多对多关系。你需要

联系
1 --- *电话* --- 1电话类型
1 --- *电子邮件* --- 1 EmailType

如果您需要与其他联系人共享电话或电子邮件，请：

联系
* --- * *电话* --- 1电话类型
* --- *电子邮件* --- 1 EmailType

这是基本的数据库设计。我建议你阅读一些例子来给你更多的想法。

编辑：我发现了一个简单的图表来帮助： http://imar.spaanjaars.com/Images/Articles/N-LayerDesign/DatabaseDiagram.jpg

完整的例子在“设计 - 收集要求”部分 http://imar.spaanjaars.com/416/building-layered-web-applications-with-microsoft-aspnet-20-part-1

如果您想要参考表，可以添加PhoneType（家庭传真，工作传真，家庭电话等）或EmailType（家庭，工作）表。

Answer 3

一个人可以拥有零个或多个地址，零个或多个人可以使用一个地址。地址分配可能会随时间而变化。

这是正确答案：

Party -< PartyAddress >- Address

PartyAddress{
  partyId
  addressId
  fromDate
  toDate (nullable)
  label -> [work, home, fax, ...]
  extension (nullable)
}

TelephoneNumber : Address
EmailAddress : Address
WebSite : Address
MailingAddress : Address

抽象销售订单处理的地址很有用。这样，如果需要，您可以通过电子邮件地址完成订单。还可以轻松“列出与此联系人的所有通信方法”

Answer 4

它看起来像你需要一个'联系人'表：

contact id
customer id
first name
surname
... other fields which would have only one value per contact

还有一个电话桌

contact id
phone number
phone type (home, office, mobile, fax)

据推测，此表的主键是电话号码，因为这应该是唯一的（问题是人们输入错误的电话号码）

我认为每个联系人只有一个电子邮件地址 - 我有三个地址，一个用于工作，一个用于家庭，一个用于垃圾邮件。在工作情况下，我只会给我的工作电子邮件，因此这是存储在“联系人”表格中的电子邮件。

此架构允许您为每个客户提供多个联系人，并为每个联系人提供多个电话号码。

数据库设计很多表VS通用表？

4 个答案: