7

我目前有一个数据库,其中包含两个名为 Articles 和 Tags 的表。为了允许文章属于多个类别,我有一个多对多的关系。在性能方面有这样的设计是错误的吗?或者我应该删除这两个表之间的关系并添加第三个表作为桥梁(articlesTags)?

4

5 回答 5

18

拥有多对多关系本质上没有任何问题,您只需要创建一个连接表(这听起来就像您所指的那样articlesTags)来促进这种关系。

于 2009-08-13T18:27:50.993 回答
7

您会看到概念数据库设计(N:N 关系)与其物理实现之间的区别。无论您如何建模 N:N 关系,您都需要前面提到的 Junction Table 才能使其工作。

将真实世界的关系建模为尽可能接近真实世界并作为一般性陈述没有任何问题。清晰为王。

当涉及到任何系统中的任何性能问题时,答案通常归结为“视情况而定”。

如果您的性能问题与 WRITES 有关,那么最好使用高度标准化的结构,并且您需要那个 Junction 表。您最终将写入更少的数据,并且可以大大加快速度(尽管您可能会通过在创建插入之前进行查找来消耗这种优势)。从单个规范化表中读取也可以非常快。

如果您的问题与分析 READS 有关,则最好使用 DENORMISED 结构。如果表很大并且索引分散,则连接可能会非常消耗性能。你会牺牲很多空间来获得很多时间。

一般来说,在决定解决方案之前,您希望查看您的具体情况并权衡每种方法的优缺点。就个人而言,我总是发现在初始阶段专注于 Clarity 并在以后发现问题时重构以提高性能会更好。

于 2009-08-13T18:53:01.807 回答
4

关系模型中存在多对多关系,它只是思想的抽象。当您实施它时,您将拥有一个 article_to_tags 表:

fk_article(整数) fk_tag(整数)

cf http://en.wikipedia.org/wiki/Many-to-many_(data_model)

于 2009-08-13T18:28:03.850 回答
3

使用多对多关系没有问题。它通常是必需的。

是的,如果不使用第三个表,就不可能创建多对多关系。

于 2009-08-13T18:28:49.090 回答
2

如果这是数据所需要的,那么建立多对多关系是没有问题的,但是您需要第三个表来表示它。

于 2009-08-13T18:24:20.973 回答