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メッセージが人/チームによって意味されているかどうかを示す a またはその他の列を人/チームに追加します (これにより、クエリは関連するテーブルのFromIDandを使用することがわかりToIDます)。

チームのサイズについてはどうですか?「メンバーは利用可能なチームを閲覧し、プライベート メッセージを送信して試合を編成できます」とはどういう意味ですか? すべてのチームの規模は同じですか? チームからチームへと自由にスキップできますか? その場合、チームのメンバーを追跡し、追加のメンバーが必要かどうかを追跡する必要があります。これは、TeamテーブルまたはUserTeamジャンクション テーブルで行うことができます。

また、あなたのウェブサイトにはログイン機能が必要だと思います。基本的なチーム メンバーとチームの正式な代表者を区別することをお勧めします。したがって、チーム間でメッセージを送信 (および受信) できるのは、公式メンバー (または何でも) だけです。(単純なゲストブック タイプのソリューションを実装するつもりなら、この点は役に立たないかもしれません。)

編集。正規化のオプション。

現在のスキーマに問題はありませんが、次のように Review テーブルと Message テーブルを組み合わせることができます。

コミュニケーション

  • メッセージ ID (PK)
  • FromID (ユーザーへの FK、NOT NULL)
  • AnswerTo (MsgID への外部キー、NULL)
  • タイムスタンプ
  • レビュー/メッセージ (tinyint [通信の種類]、NOT NULL)
  • テキスト (NOT NULL)

レビュー/メッセージ列は、個人とチームの間でメッセージを区別することもできるため、FromID は TeamID の FK になることもあります。

于 2012-07-04T13:42:47.037 に答える