0

我正在尝试设计一个允许运动队更轻松地组织比赛的网站：

用户注册并加入团队。成员可以浏览可用的团队并向他们发送私人消息以组织比赛。比赛结束后，球队可以在彼此的页面上发表评论，提及他们的技能、体育精神等。这是我想象的数据库的样子：

用户

* UserID
* Username
* email

团队

* TeamID
* TeamName
* OtherInfo

审查

* FromID
* ToID
* Date
* Comments

信息

* FromID
* ToID
* Content

UserTeam（联结表）

* pk (UserID, TeamID)

我不太确定如何为评论和消息建模。评论有一个 from 和一个 to 字段，所以我不能像在多对多情况下那样通过使用联结表来规范化设计。

注意：消息可以由成员和团队发送，并且可以由成员或团队接收。

4

1 回答 1

1

不确定问题是什么，但如果您的消息（和评论？）可以由团队或成员发送和接收，您需要区分消息的目的。添加一个tinyint或其他一些列，指示消息是否由个人/团队向个人/团队表示（因此您的查询知道使用相关表的FromIDand ToID）。

团队规模如何？您所说的“成员可以浏览可用的团队并向他们发送私人消息以组织比赛”是什么意思？所有团队的规模都一样吗？人们可以自由地从一个团队跳到另一个团队吗？如果是这样，您需要跟踪团队成员以及是否需要其他成员。您可以在Team表或UserTeam联结表中执行此操作。

我还猜测您的网站需要登录功能。区分基本团队成员和团队的官方代表可能是一个好主意。因此，只有官方成员（或其他）能够在团队之间发送（和接收！）消息。（如果您打算实现一个简单的留言簿类型的解决方案，这一点可能没用。）

编辑。标准化的一个选项。

我在您当前的架构中没有发现任何问题，但您可以像这样组合 Review 和 Message 表：

沟通

  • 消息 ID (PK)
  • FromID（FK 到用户，NOT NULL）
  • AnswerTo（FK 到 MsgID，NULL）
  • 时间戳
  • 评论/消息（tinyint [通讯的类型]，NOT NULL）
  • 文本（非空）

Review/Message 列还可以区分人员和团队之间的消息，因此 FromID 也可以是 FK 到 TeamID。

于 2012-07-04T13:42:47.037 回答