0

我正在编写一个应用程序，它具有类似于 Google Circle/FB 好友列表的某些功能。

  1. 用户可以将他们认识的人分组（家人、同事、朋友等）（目前不能嵌套组）
  2. 用户可以向群组发送消息、为每个群组设置隐私设置等
  3. 当帖子在组内共享时，这些组的用户可以评论并查看其他人的评论，无论他们与其他人（在该组内）的关系如何

目前，由于时间和资源的限制，我们正在使用关系数据库（mysql）。无论如何，我都在努力寻找构建数据库以平衡性能和清晰度的最佳方式。这是我们目前拥有的：

users:
  user_id
  default_group_id
  friend_group_id

groups:
  group_id

groups_to_users:
  user_id
  group_id

messages:
  message_id

messages_to_groups:
  message_id
  group_id

galleries_to_groups:
  gallery_id
  group_id

首次创建用户时，他/她将有 2 个基本组：

  1. 仅包含该单个用户的默认组
  2. 将包含他/她是朋友的每个人的朋友组

我们将简单地使用 group_id 来确定“权限”，而不是使用 user_id。这样我们就可以跳过查询 2 个表的复杂性。

同时，使用上面的结构，我们也遇到了查询用户收到的所有消息的障碍，因为如果该用户有 100 个朋友，我们可能必须查询至少 100 个组。所以现在我们通过这个相当老套的方法来解决这个问题：

如果用户向组发送消息，那么我们会遍历该组中的成员列表并为每个用户保存一条记录（message_id，（default_）group_id）。问题是，如果该组有 1000 多个成员，那么我们必须为发送到该组的每条新消息插入 1000 多个记录，并且当该用户对组成员进行任何更改时，我们还必须更新大量的记录。

我想知道是否有更好的方法来构建我们的数据库以提高性能？

4

2 回答 2

1

您的“hacky 方法”违背了建立群组的目的，因为您实际上是在编写个人链接，而不是使用他们的群组成员身份来合理化您的交易（即消息）。如果您关心的是性能，那么通过将您的写入乘以 100 或 1000 倍，您的读取可能不会获得巨大的提升。

我认为您应该坚持原始设计并确保您的表已正确索引，以便 DBMS 可以执行其构建的任务 - 快速有效地连接数据集。

如果您将表设计为具有正确类型的主键和外键，并且如果您设计查询以便它们利用 PK/FK 索引，那么这就是您优化性能的方式。

于 2011-08-22T11:43:20.417 回答
0

树结构适合表示这种分层数据

例如 { <user> <guid>uid1</guid> <message>msgid2</message> </user> <user> <guid>uid2</guid> </user> <group> <guid>groupid1</ guid> <member>uid1</member> </group> <group> <guid>groupid2</guid> <member>uid1</member> <member>uid2</member> <message>msgid1</message> < /group> } 让数据模型可以灵活查找

  • 将消息发送给单个用户或组
  • 特定用户的消息列表是发送给用户所属组列表的消息和直接发送给用户的消息的累积
于 2011-08-22T07:31:07.600 回答