1

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

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

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
++++++++++++

我能想到的优点和缺点是：

优点1：

您将始终搜索索引，更快的查询示例选择 where uid=1，然后选择链接 1,3。两者都是索引，因此加载速度很快。

如果您有 1000 个用户，并且他们每个人都有 20 个链接，这意味着您必须通过 20.000 条记录才能获得所有链接（我认为，不确定这一点）。使用这种方法，你只需要一个索引就可以了。

缺点1：

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

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

缺点2：

另一个缺点是当您删除链接 2 时，您必须遍历所有字符串，但可以说这不是什么大问题，因为这种情况不会经常发生。

到目前为止，这是我能想到的，而我正处于我的项目的关键点，我必须决定选择哪一个。

我很想就选择哪种方法提供一些建议。我有我的优点和缺点吗？有没有我没有考虑的事情。对此主题的任何帮助将不胜感激。

谢谢你们！

4

3 回答 3

3

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

  • 您无法有效地加入名称和链接（FIND_IN_SET不可分割）

  • 您不能使用FOREIGN KEYs(in InnoDB)强制引用完整性

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

如果您从不搜索给定链接的名称并且链接数量很少，那么您可能会因摆脱额外的连接而受益。

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

如果links已修复，您可以考虑改用本机SET数据类型。

于 2010-02-27T22:57:16.347 回答
0

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

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

于 2010-02-27T22:54:37.890 回答
0

我绝不是数据库专家，但你的第二个选择让我觉得这是一个非常糟糕的主意。即使假设您永远不需要，比如说，通过 name_link 表中的链接进行搜索，对链接做任何事情都将是很多（不必要的，IMO）额外工作。

于 2010-02-27T22:55:39.580 回答