小编mul*_*uin的帖子

TLDR；以下场景的最佳设计选择是什么，每个设计在极大数据量下会如何反应？

我有使用大型政府数据库系统服务 24/7 数据收集、处理和报告的经验。浏览所有不同设计的模式并了解所有这些不同的人设计的所有这些功能如何以某种方式混杂成一个有效的解决方案是很有趣的。就像我相信你们中的一些人知道的那样，有趣的戳时间是一种奢侈，而且大多数周期都是务实的，让系统保持活力而不是改进设计。

我一直在建模一个新的数据库系统，并想对如何关联这些实体有一些想法。

场景：客户、雇主和从业者需要电话号码。

我们有四个实体：

• CLIENT
• EMPLOYER
• PRACTITIONER
• PHONE

电话号码按用于接听电话的技术进行分类，所使用的技术通知数据格式限制。

• 座机
• 传真
• 移动的

描述字段指示电话的主要用途；家庭、工作等。

关联这些实体的方法

1. 反规范化PHONE为CLIENT, EMPLOYER,PRACTITIONER

让我们从糟糕的设计开始，然后从那里开始。去规范化所有的电话号码！

• 3 个实体，没有关系
• 如果需要新电话号码，则必须创建新列；导致CLIENT.Phone1Number, EMPLOYER.Phone2Type, PRACTITIONER.Phone3Description;
• 或限制可以为每个实体输入的电话号码数量
• 冗余，大量开销
• 进行批量更新或维护会变得乏味

结论：select * from 'no_thanks';

2.建造第n座桥；重命名数据库匹兹堡

对于可以关联电话号码的每个实体，创建一个桥实体将它们组合在一起。

• 7 个实体，6 个关系
• 数据冗余；电话号码填充在多个位置
• 仅PhoneNumber在需要时可以使用桥接表；不需要 JOIN 即可PHONE
• 如果新实体FAMILYMEMBER需要电话号码，则必须创建新的桥接表

结论：也许，取决于维持关系的难度

3. 一个准“星图”

修改PHONE以包含CLIENT.ClientID, EMPLOYER.EmployerID, 的外键 …