MySQL查询正常关系表VS串联realtionship表(mysql query normal r

2019-10-20 02:40发布

我有一个关于两个表之间的关系问题。

比方说,我们有一个表的用户,和链接。

users
+++++++++
id name
1  name1
2  name2
3  name3
+++++++++

links
+++++++++
id link
1  link1
2  link1
3  link1
+++++++++

现在,这两个链接的正常方式是用name_links表。 例如:

name_links
++++++++++++
uid  lid
1    1
1    3
2    3
2    1
2    2
3    2
++++++++++++

现在,我想知道,如果它是一个好主意,做一个表像这样

name_links
++++++++++++
uid  lid
1    1,3
2    1,2,3
3    2
++++++++++++

我能想到的利弊:

PROS1:

你总是会在索引搜索,更快的查询例如选择其中uid = 1,然后选择链接1,3。 两者都是索引所以这将是一个快速加载。

如果你有1000个用户,而他们每个人都有20个链接,这意味着你必须走线槽20.000记录,让所有的链接(我想,不知道这个问题)。 使用这种方法,你只需要一个索引,和你做。

cons1:

你将不得不更频繁地更新name_links表,读取,编辑和写例如用户2删除链接2的方法是:
+获得的用户1串
+从字符串中删除数
+插入新的字符串

这里的一切都在索引完成,所以我认为这将是快。

cons2;

另一个con是,当你删除链接2,你有走线槽的所有字符串,但可以说这是不是太大的问题,因为这不会经常发生。

这是我能拿出什么用,到目前为止,我在我的项目的地步,我必须决定与去。

我很想对选择哪种方法一些建议。 我有我的优点和缺点吧? 有没有一些事情我不是在考虑采取。 有关这个主题的任何帮助将不胜感激。

感谢大伙们!

Answer 1:

非标准化的解决方案有这些缺点:

  • 你不能有效地加入名称和链接( FIND_IN_SET不是可优化搜索)

  • 您不能使用强制参照完整性FOREIGN KEYs (在InnoDB

  • 删除和添加名称链接关系更为复杂

如果你从来没有搜索提供的链接名称和链接数量很少,你可能通过摆脱额外的受益加盟。

你应该确保的性能优势是真实的,你真的需要它,你都知道维护一个非规范化表的并发症。

如果links是固定的,你可以考虑使用原生SET数据类型来代替。



Answer 2:

你绝对不应该串连记录,除非你绝对必须的。 考虑未来的能力,可以说你要计算有多少用户连接3,这是你的第二个方法的疼痛。

所以,我认为你的榜样,这将是一个多到多加入,这意味着一个链接可以连接到许多用户和许多用户可以通过链接来连接。 所以,你可能有一个有一个用户连接到一个链接,像time_linked,可以去上你的name_links表做的属性。



Answer 3:

我绝不是一个数据库专家,但你的第二个选项,在我看来是一个非常糟糕的主意。 即使assumming你永远需要,比方说,在name_link表通过链接做搜索,做与任何链接会有很多的(不必要的,IMO)额外的工作。



文章来源: mysql query normal relationship table vs concatenated realtionship table