规范化或非规范化:将联系人详细信息(电话号码)存储在单独的表中？搜索性能？

我正在设计一个存储简单联系信息(名/姓等)的数据库应用程序,我还需要存储电话号码.除了电话号码,我必须存储它们的用途(移动电话,商务等),并且可能还有其他评论.

我的第一种方法是规范化并将电话号码保存在一个单独的表中,这样我就可以使用"联系人"和"电话号码"表.PhoneNumbers表是这样的:

Id int PK
ContactId int FK<->Contacts.Id
PhoneNumber nvarchar(22)
Description nvarchar(100)

但是,如果我只是将这些信息存储为每个联系人记录的一部分(假设我限制了可以存储的电话号码总数,总共4个数字),那么它会使事情变得更容易并且在检索时保存SQL Join. .

但是,我最终得到了一个像这样的"丑陋"结构:

PhoneNumber1 nvarchar(22)
Description1 nvarchar(100)
PhoneNumber2 nvarchar(22)
Description2 nvarchar(100)

等等

它看起来很业余,但我看到的优点是:

1)在ASP.NET MVC中,我可以简单地将输入文本框附加到我的LINQ对象的属性中,并且完成了连接记录添加和更新.

2)无需SQL连接来检索信息.

不幸的是,我对表宽问题等问题不是很了解(我读过如果它变得太大/太多列并且出现性能问题会导致问题吗？)然后它也意味着当我搜索一个问题时电话号码如果我将它保存在一个单独的表中,我必须查看4个字段而不是1个字段.

我的应用程序有大约80%的搜索/数据检索活动,因此搜索性能是一个重要因素.

感谢您帮助我找到正确的方法.单独的桌子或保持一个？谢谢!

它不会导致数据非规范化的问题,但我不建议.尽管查询可能更复杂,但最好是拥有可以通过多种方式操作的格式良好的数据.我会建议像这样的数据库模式:

Contacts:
  ID (Primary Key)
  Name
  Job Title

Phone Number Categories:
  ID (Primary key)
  Name

Phone Numbers:
  ID (Primary Key)
  Category_ID (Foreign Key -> Phone Number Categories.ID)
  Contact_ID (Foreign Key -> Contacts.ID)
  Phone Number

这使您可以在允许的电话号码数量上获得很大的灵活性,并使您能够对它们进行分类.

这可能现在很好,但当有人想要第五个电话号码时会发生什么？你一直在增加越来越多的领域吗？

另一件需要考虑的事情是你如何运行查询来说"给我所有人和他们的手机号码",或"给我每个人没有电话号码"？使用单独的表格,这很容易,但是使用一个表格,移动电话号码可以在四个字段中的任何一个中,因此它变得更加复杂.

如果采用规范化方法,并且将来要添加有关电话号码的其他数据,则只需在电话号码表中添加另一列,而不是向联系人表中添加4列.

回到有关未来添加更多电话号码的第一点 - 如果你确实增加了更多的号码,你将不得不修改每个查询/逻辑/形式的数据,这些逻辑/表格与电话号码有关.