1

我目前正在设计一个 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

所以现在我在 PHP 中使用带有这个数据库模型的 ORM 并发现自己处于我有一个 Fax-Object 的实例以及加载相应提供程序的内容的情况下。

现在这将花费我一个大连接或几个查询。

我需要走的路是：

Fax -> Letter -> Address -> Provider

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

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

4

2 回答 2

5

好吧，识别关系和“更自然”的键可以降低对 JOINing 的需求。

例如：

在此处输入图像描述

既然有Faxes.ProviderId，就可以直接JOINFaxes和Providers.

并且由于InnoDB 表是集群的，如果您朝相反的方向前进（例如“获取给定提供商的所有传真”），您可以期待良好的性能。

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

于 2012-06-14T09:44:35.630 回答
2

您可以做的是将提供者后续表作为弱实体相互关联——其中每个表的标识主键的一部分依赖于另一个表（通过 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>
于 2012-06-14T09:40:34.510 回答