Database design 数据库设计多表还是通用表？

我们的数据库设计有问题。我们必须将我们的客户联系信息模式分解为单独的表：

电话表、电子邮件表、传真表

等，然后我们在主

客户

表和不同联系人表之间建立了

多对多

关系

例如，如果客户在不同的地点工作，并与其他客户共享不同的联系信息，则客户可以有许多电话号码。 我正在尝试创建一个通用表来保存所有形式的联系人数据，并为

联系人类型

字段创建一个查找表，其中包含标签值，如

个人、电子邮件、工作电子邮件、家庭电话、手机、工作电话、家庭传真、工作传真、工作网站等

---

您建议采用哪种设计？

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

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

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

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

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

编辑： 我找到了一个简单的图表来帮助：

完整示例见“设计-收集要求”一节

---

如果需要参考表，您可以添加电话类型（家庭传真、工作传真、家庭电话等）或电子邮件类型（家庭、工作）表。

它看起来像是您需要一个“联系人”表：

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)

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

我认为每个联系人只有一个电子邮件地址——而我有三个地址，一个是工作地址，一个是家庭地址，一个是垃圾邮件地址。在工作情况下，我只会给我的工作电子邮件，所以这是一个存储在'联系人'表

---

此模式允许每个客户有多个联系人，每个联系人有多个电话号码。

作为多年从事数据库工作的人员，请创建单独的表。首先，最终您可能需要不同的字段（我知道我们的电话表和电子邮件表有不同的结构）。第二，您所描述的模型是一个简单的模型，在性能和数据完整性方面，它通常都是一个糟糕的选择（很难实施您需要的所有FK）

---

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

一个人可以有零个或多个地址，一个地址可以被零个或多个人使用。地址分配可以随时间而改变

这是正确的答案：

Party -< PartyAddress >- Address

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

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

参与方--地址
PartyAddress{
partyId
地址ID
起始日期
toDate（可为空）
标签->[工作、家庭、传真等]
扩展名（可为空）
}
电话号码：地址
电子邮件地址：地址
网站：地址
邮寄地址：地址

---

为销售订单处理提取地址很有用。这样，如果您愿意，您可以通过电子邮件地址完成订单。还可以方便地“列出与此联系人的所有通信方法”

任何一种方法都有效，并且每种方法都有优点和缺点。我认为这个问题是正确的，但就其措辞而言，我相信它会引发关于“最佳”方法的争论，因此根据网站定义，它不是建设性的，即：就目前情况而言，这个问题不适合我们的问答形式。我们希望答案能得到事实、参考资料或特定专业知识的支持，但这个问题可能会引发辩论、争论、投票或广泛讨论。对我来说，我是这个项目的初级开发人员，也是唯一的开发人员，因为我正试图自己找出最佳解决方案，如果您提供表结构，那么aelnajjar将更容易理解。