好的，我被告知我的最后一个问题太宽了，所以我这次尝试的更精确。
我需要MessageBoard应用程序的数据库结构。 我有2个想法，但不知道哪个更好。 还有另一种可能性比我的想法更好吗？
有用户，消息和组。 所有消息都属于至少一个组，但可以更多。 用户至少订阅一个组，并且可以查看他们所属的所有组的所有消息。 用户可以随意创建组。
量表（理论上）： 用户：百万 消息：数十亿 群组：超过用户
我现在有两个想法：
创意1：
表用户：
表格消息：
表组：
想法：
消息获取：
消息写：
创意2：
表用户：
表格消息：
表组：
点子：
消息获取：
消息写：
答案 0 :(得分：1)
这是@Paul Spiegel在上面指出的数据库规范化练习。
您可以创建以下内容：
用户的
- UserID PK
- ImageURI
- ...个人用户信息栏......
消息
- MessageID PK
- 文本
- UserID FK - ＆gt;用户（UserID）//消息作者（创作者）
- 日期
回复
- MessageID FK - ＆gt;消息（邮件ID）
- ReplyID FK - ＆gt;消息（邮件ID）
- PK（MessageID，ReplyID）
组
- GroupID PK
- 名称
- 描述
- UserID FK - ＆gt;用户（UserID）//组主持人 - 我只是为了好玩而添加这个。
User_Groups
- UserID FK - ＆gt;用户（用户ID）
- GroupID FK - ＆gt;组（组ID）
- PK（UserID，GroupID）
Message_Groups
- MessageID FK - ＆gt;消息（邮件ID）
- GroupID FK - ＆gt;组（组ID）
- PK（MessageID，GroupID）
我假设它是用户头像，我将ImageID从消息移动到用户。如果它确实与消息相关联，那么将其移回。
除了已包含的PK和FK之外，还有三个应用程序完整性规则。
AIR＃1 - Messages中存在一行意味着Message_Groups中至少有一个匹配的行。
AIR＃2 - Users中存在一行意味着User_Groups中至少有一个匹配的行。
AIR＃3 - 给定的ReplyID只能在回复中出现一次。这保持了邻接列表语义，防止了广义的多对多关联并强制执行分层关联。
数据库连接逻辑和应用程序代码留给读者练习。