数据库设计中的多对多关系

Question

我目前有一个数据库，其中有两个表称为文章和标签。为了让文章分为多个类别，我有多对多的关系。在性能方面有这样的设计是错误的吗？或者我应该删除这两个表之间的关系，并添加第三个表作为桥梁（articlesTags）？

Answer 1

拥有多对多关系本身并没有什么错误，您只需要创建一个Junction Table（这听起来就像您指的是articlesTags）以促进这种关系。

Answer 2

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

Answer 3

关系模型中存在多对多的关系，它只是一个抽象的思维。 当你实现它会有一个articles_to_tags表，你将有：

fk_article（整数） fk_tag（整数）

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

Answer 4

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

是的，无法使用第三个表创建多对多关系。

Answer 5

您将看到概念数据库设计（N：N关系）与物理实现之间的区别。不管你如何模拟你的N：N关系，你都需要上述的连接表来使它工作。

将真实世界的关系模拟为与真实世界接近的一般性陈述并没有错。清晰是国王。

当谈到任何系统中的任何性能问题时，答案通常归结为“取决于”。

如果你的性能问题与WRITES相关，那么高度的NORMALIZED结构是最好的，你会需要该Junction表。你最终会写更少的数据，并且可以大幅度提高速度（尽管你可能会在创建插入之前先进行查找来消化这些优势）。从各个标准化表中读取也可以非常快。

如果您的问题与分析性阅读有关，那么DENORMALISED结构是最好的。如果表格很大并且索引展开，连接可能会非常耗费性能。你会牺牲很多空间来获得很多时间。

一般来说，在决定解决方案之前，您需要查看自己的具体情况并权衡每种方法的优缺点。就个人而言，如果我稍后发现问题，我总是发现在初始阶段专注于清晰度并重构性能会更好。