1

我简单的例子可以是这样。我有电影桌，电影有导演和演员。在我的数据库中，一部电影可以有一个或多个导演和一个或多个演员。我还有一个表格 Persons ，其中包含人员的信息。所以一个人可以在电影中扮演不同的角色，我有另一个表，它有可能的角色，表角色。

在许多情况下，我会对了解电影的导演或演员感兴趣，因此我可以通过两种主要方式来分配表格。

第一种选择：三元关系：

Movies(IDMovie, ...)
Persons(IDPerson, ...)
Roles(IDRol,...)
MoviesPersons(IDMovie, IDPerson, IDRol...)

在这种情况下，我使用三元关系。

第二个选项是：

MoviesDirectors(IDMovie, IDPerson,...)
MoviesActors(IDMovie, IDPerson,...)

在这种情况下，我可以从关系表中推断出角色。

哪个是最好的选择？

谢谢。

编辑：如果我使用两个二元关系的选项，如果将来，如果我想要配乐的作曲家，我需要创建一个新的表和关系，但是，使用三元关系我不需要什么都不做，只在角色表中添加一个新角色和其他任何东西。

在性能上两个二元关系比一个三元关系更好？

谢谢。

4

1 回答 1

1

哪个是最好的选择？

您几乎回答了您自己的问题 - 如果您希望在不改变数据库结构的情况下灵活地在未来添加新角色，那么三元关系就是您的最佳选择。

如果它们中的每一个都需要具有不同的字段或约束（根据您的描述，情况似乎并非如此），我会考虑单独的二元关系。

在性能上两个二元关系比一个三元关系更好？

由于表示三元关系的表需要物理存储角色标识符（与从表名本身推断角色的二元关系相反），因此您的缓存使用率会稍差。

但是，通过对复合 PK 中的字段进行仔细排序，可以使三元关系更适合某些类型的查询。例如，PK:{IDMovie, IDRol, IDPerson}可以有效地支持以下查询：

  • 哪些人在给定的电影上工作过？（X）
  • 哪些人在给定的电影中以给定的角色工作过？

如果您在: 上创建索引{IDPerson, IDRol, IDMovie}，您还可以有效地查询：

  • 给定的人参与过哪些电影？（X）
  • 给定的人在给定的角色中工作过哪些电影？

(X)对于单独的二元关系，您需要查询每个联结表。这当然不是只有两张表的问题，但是随着表的数量增加（当然从维护甚至从性能角度来看），它可以变成一张。

于 2013-04-21T17:30:55.093 回答