我目前有一个数据库，其中有两个表，分别称为 Articles 和 Tags 。为了允许文章属于多个类别，我有多对多的关系。这样的设计从性能上来说是不是一个错误呢？或者我应该删除这两个表之间的关系并添加第三个表作为桥梁（articlesTags）？
多对多关系本质上没有什么问题，您只需要创建一个 Junction Table（听起来就像您用
articlesTags您将看到概念数据库设计（N:N 关系）与其物理实现之间的区别。无论您如何建模 N:N 关系，您都需要前面提到的连接表才能使其发挥作用。
将现实世界的关系建模为尽可能接近现实世界的一般性陈述并没有什么问题。清晰才是王道。
当涉及任何系统中的任何性能问题时，答案通常归结为“这取决于”。
如果您的性能问题与写入有关，那么高度规范化的结构是最好的，您将需要该连接表。您最终将写入更少的数据，并且可以大大加快速度（尽管您可能会因在创建插入之前必须进行查找而失去这一优势）。从各个标准化表中读取数据也可以非常快。
如果您的问题与分析读取有关，那么非规范化结构是最好的。如果表很大并且索引分散，那么连接可能会非常耗费性能。您将牺牲大量空间来赢得大量时间。
一般来说，在决定解决方案之前，您需要考虑具体情况并权衡每种方法的利弊。就我个人而言，我总是发现在初始阶段专注于清晰度并在以后发现问题时重构性能会更好。
关系模型中存在多对多关系，它只是思维的抽象。 当您实现它时，将会有一个articles_to_tags表，您将在其中拥有：
fk_文章（整数） fk_tag(整数)
使用多对多关系没有问题。经常需要。
是的，如果不使用第三个表，就不可能创建多对多关系。
如果数据需要的话，建立多对多关系没有问题，但您需要第三个表来表示它。