2

我正在使用 SQL Server 2008。我的问题是关于关系数据库设计。我得到了以下表格和关系：

合同：我与Laborer 有1-M 关系。我们预计会有 50 万份合同。合同是两方之间的商业合同。

劳动者：每组劳动者属于一份合同。我们期待数以百万计的劳动力。

消息：预计包含数百万条记录。向合同方发送有关合同和劳工的消息。

MessageContract：Message 和 Contract 之间的桥梁表，预计有数百万条记录。

MessageLaborer：Message 和 Laborer 之间的桥接表，预计有数百万条记录。

Process : 与 Message 有 1-M 的关系。预计最终会有数十万条记录。

我的问题是除了Process和Message之间的关系之外，是否可以添加Process和MessageContract和MessageLaborer之间的关系，这样在查询正在处理的合同和劳动者时，我就​​不必添加与Message的join。

另一个例子：MessageLaborer 与 MessageContract 有间接关系。您可以随时查询数据库以获取每个合同消息下的劳动者，但您需要 4 个连接来执行此操作。另一种选择是在 MessageLaborer 和 MessageContract 之间创建另一个关系，因此您只需要一个联接。

这是常见的做法还是常见的错误？

4

3 回答 3

2

只有当它们具有多对多关系时，在两个关系之间建立一个桥接表才有意义——它将多对多解析为一对多对一。

如果您需要定义一条消息，然后将其发送到多个合约，则使用消息和合约之间的桥接表。如果消息仅适用于单个合约，则不需要桥接表。

不要引入新表来连接已经自然连接的关系。您将破坏规范化形式为每个事实提供单一事实来源的能力。但是，如果您有两个父表的子表，通常可以通过加入它们的外键列来连接它们，而无需通过父表。

于 2013-06-30T15:43:15.140 回答
1

数据库设计中最常见的错误是添加了太多的关系。实现 1:N 关系很复杂。很容易编写一个客户端应用程序来更新一个总是有两个地址的客户。为具有 0..N 个地址的客户编写客户端应用程序要困难得多。

例如，如果一条消息最多与一个合同相关，您可以删除该MessageContract表。创建消息的客户端（或业务层）现在少了一张需要担心的表。显示消息的客户端可以使用列表框而不是网格视图。轻松多了！

于 2013-06-30T12:16:58.817 回答
-1

您可以将关系数据库建模过程视为使您的系统了解现实世界的一部分。因此，如果您的数据库必须了解现实世界中的关系，那么也应该存在真正的数据库关系。

不要仅仅因为你需要一个 JOIN 就添加你的数据库关系。这部分属于查询优化。

于 2013-06-30T13:02:46.293 回答