Question

我对两个表之间的关系有疑问。

假设我们有一个表用户和链接。

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删除link2，方法将是：
    +获取用户1的字符串     +从字符串中删除数字
    +插入新字符串

这里的所有内容都是在索引上完成的，所以我认为它会很快。

cons2：

另一个骗局是当你删除链接2时，你必须通过所有字符串，但是我们可以说这不是一个问题，因为这不会经常发生。

到目前为止，这是我能想到的，而且我正处于我的项目中，我必须决定去哪个。

我希望对选择哪种方法有一些建议。我有自己的利弊吗？有没有我考虑的事情。任何有关此主题的帮助都将受到高度赞赏。

谢谢你们！

Answer 1

非规范化解决方案存在以下缺点：

如果您从未搜索过指定链接的名称且链接数量很少，您可能会因为删除额外的加入而受益。

你应该确保性能优势是真实的，你真的需要它，并且你知道维护非规范化表的复杂性。

如果links已修复，您可以考虑使用原生SET数据类型。

Answer 2

除非绝对必须，否则绝对不应该连接记录。考虑未来的能力，假设您想要计算有多少用户拥有链接3，这对您的第二种方法来说是一种痛苦。

因此，我假设您的示例将是多对多连接，这意味着链接可以连接到许多用户，并且许多用户可以通过链接进行连接。因此，您可能具有与连接到链接的用户有关的属性，例如time_linked 这可以放在你的name_links表上。

Answer 3

我绝不是数据库专家，但你的第二个选择让我感到非常糟糕的想法。甚至假设您永远不需要，比如在name_link表中通过链接进行搜索，对链接执行任何操作都将是很多（不必要的，IMO）额外工作。