Sql 多对多关系简化

考虑以下两个表：

Messages
MessageId (PK)
Text  

Languages
LanguageId (PK)
Language

消息和语言表之间存在多对多关系（即每条消息可以有多种语言，每种语言可以由多条消息共享）。为此，我添加了以下连接表：

Messages_Languages
MessageId (PK)(FK)
LanguageId (PK)(FK)

但是，它似乎有些不必要，因为语言从根本上来说是消息的属性。使用上面的Messages_Languages表而不是将LanguageId作为外键添加到Messages表有什么好处？（见下文）

---

似乎用少一张表就能完成同样的事情。

这是一个非常好的简单示例。根据您的简单示例，最好将LanguageID作为属性添加到表中，因为您是正确的：它实际上只是一个属性。可能存在固定数量的语言，并且应用程序的用户在使用应用程序时不会添加新语言

在进一步开发应用程序时，这是否成立是另一个问题。如果您添加消息版本或其他一些附加列的概念，那么使用单独的表可能是有意义的

它似乎完成了同样的事情

否。连接表模型为多对多，而FK模型为一对多

---

所以问题不在于哪一个更好，而在于你需要哪一个？

问题不在于你能做什么，而在于你做的事情是否正确。 问问自己：

单个消息是否将连接到多种语言和 语言可以连接到许多消息

这是一种多对多关系，您应该为其设置连接表

若您只需要为单个消息提供一种语言，那个么使用语言id作为消息的属性。这称为一对多关系

要显示这两者在某些数字上的差异，请执行以下操作：

在表

Messages\u Languages

中，可以有行：

1,1
1,2
1,3
2,1
2,2
2,3

在最后一张桌子上：

Messages  
MessageId (PK)
LanguageId (PK)(FK)
Text  

您将能够：

1,1
2,3
3,2

---

只需将languageid添加到messages表就可以满足我的需要。然而，我基本上不理解为什么我能够使用这种方法对这种多对多关系进行建模，而建模这种关系通常需要一个连接表。为什么你认为你只需要一个FK就可以对多对多关系进行建模？在这种情况下，一条消息可以只有一种语言，这就形成了“一（语言）对多（消息）”的关系。基本上，我的文章的全部观点是，您选择的解决方案取决于您的需求，我们无法为您定义需求。如果您需要一条消息使用多种语言（例如多个翻译），则需要多对多（连接表）。如果给定的消息一次只能使用一种语言，那么一对多就是您所需要的（FK）。谢谢，我明白了！看来我误解了这段关系的本质。

1,1
2,3
3,2