关系数据库设计：如何设计长路径的关系？

Question

我目前正在设计一个MySQL数据库，我遇到了以下问题，我不确定如何正确解决/设计。

我有实体:(简化）

Providers, Addresses, Letters, Faxes

现在：

Adresses belong to providers, Providers have many Addresses

Letters belong to Addresses, Addresses have many Letters

Faxes belong to Letters, Letter have many Faxes

所以现在我正在使用带有此数据库模型的ORM在PHP中工作，并发现自己处于一种情况，即我有一个传真对象的实例以及加载相应提供者的内容。

现在，这将要么花费我大量的连接或几个查询。

我需要走的路是：

Fax -> Letter -> Address -> Provider

现在我在想是否应该在传真和提供商之间建立直接关系，这将解决这个问题。但这不是多余的，而是以双重努力为代价的吗？如果传真和提供商之间的关系发生变化怎么办？然后我会调整两个关系路径。

这样做的首选方式是什么？我的例子有点简化。实际上，我必须走的路要长一点。

Answer 1

那么，识别关系和“更自然”的关键可以降低对JOIN的需求。

例如：

由于Faxes.ProviderId，您可以直接加入Faxes和Providers。

从InnoDB tables are clustered开始，如果您朝相反的方向前进，可以获得良好的表现（例如“获取给定提供商的所有传真”）。

缺点是“更胖”的键和对ORM的相对不友好。所以，我想这是一个妥协的问题，你就是决定哪个选项更好的人。

Answer 2

您可以做的是使提供者 - 后续表彼此相关为weak entities - 其中每个表的标识主键的一部分依赖于另一个表（通过1：N 标识关系）。您可以这样建模：

providers
-----------------
provider_id   [PK]
...


addresses
-----------------
provider_id   [PK] (FK Referencing providers.provider_id)
address_id    [PK]
...


letters
-----------------
provider_id   [PK] (FK Referencing addresses.provider_id)
address_id    [PK] (FK Referencing addresses.address_id)
letter_id     [PK]
...


faxes
-----------------
provider_id   [PK] (FK Referencing letters.provider_id)
address_id    [PK] (FK Referencing letters.address_id)
letter_id     [PK] (FK Referencing letters.letter_id)
fax_id        [PK]
...

这样，给定一个特定的传真记录，您只需要找到关于相关提供者的更多信息，您只需加入一个表，如下所示：

SELECT 
    subj,
    content
FROM
    faxes
INNER JOIN
    providers USING (provider_id)
WHERE
    fax_id = <faxid here>