Database design 我应该如何构造此组/角色架构？

我正在写一个应用程序，它有一些类似于谷歌圈/FB好友列表的特性

用户可以将他们认识的人放入组中（家人、同事、朋友等） （目前无法嵌套组）

用户可以向组发送消息，设置每个组的隐私设置等

在组内共享帖子时，这些组的用户可以发表评论并查看其他人的评论，而不管他们与其他人（在该组内）的关系如何

目前，由于时间和资源的限制，我们正在使用关系数据库（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个基本组：

仅包含该单个用户的默认组

朋友组，其中将包含他/她是朋友的每个人

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

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

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

---

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

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

比如说 { uid1 msgid2 uid2组ID1 uid1组ID2 uid1 uid2 msgid1 } 因此，数据模型可以灵活地查找

• 发送给单个用户或组的目标消息
• 特定用户的邮件列表是指向该用户所属组列表的邮件和直接指向该用户的邮件的累积

你的“黑客方法”违背了建立团体的目的，因为你实际上是在写个人链接，而不是使用他们的团体成员身份来合理化你的交易（即消息）。如果您关心的是性能，那么您可能不会通过将写操作乘以100或1000的系数来大幅提高读取速度

我认为您应该坚持最初的设计，并确保您的表被正确地索引，以便DBMS能够完成它构建的目的，即快速高效地连接数据集

---

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

没错，不需要发送1000多条这样的消息，我们可以使用当前的结构并使用join代替NAGESWARA Rao，您能否详细说明如何将数据存储在数据库中？我在这里有点慢，你可以通过在组中引入一些冗余来解决这个用例，例如用户到组-------------------user\u id---->userid user\u id---->groupid messages\u-to\u-group-------------------group\u-id-->message\u-id user\u-id---->message\u-id。所以，如果你想让组的成员按照组的id查询组到用户