1

私は現在、（イベントのボランティアスタッフ配置用の）スケジューリングWebアプリを構築する計画段階にあり、経験豊富な人に質問があります。

背景：イベントのカレンダーがあり、いつでもすべてのユーザーが任意のイベントに登録できます。後で、そのイベントの前に、管理者の1人がステップインして、登録したものから「スタッフリスト」を選択し、残りは「代替リスト」に入れられます。

これまで私が考えていたのは、Eventテーブル、Userテーブル、そして他に3つのテーブルがあるということです。

  • UserEvent
    • ユーザーを登録したイベントにマップします。スタッフまたはAltリストのメンバーシップを意味するものではありません。
  • UserStaff
    • ユーザーを登録したイベントにマップし、たまたまスタッフを配置します。
  • UserAlt
    • UserStaffに似ています

次に、質問は2つの部分になります。

  • これはそれを行うための良い方法ですか？
  • これらの3つの関連テーブルのそれぞれに、ユーザーIDとイベントIDを含める必要がありますか？

その2番目の質問は本当に私が議論してもらいたいものです。これは重複したマテリアルが多いように思われるため（UserStaffまたはUserAltのすべてが常にUserEventに含まれる）、複合キーに加えて、他のテーブル（UserStaffおよびUserAlt）が参照します。プラス面では、重複するコンテンツが少なくなり、マイナス面では、この方法でほとんどすべてのクエリで参照する必要がある中間テーブル（UserEvent）があります。

うまくいけば、私は十分に明確になりました、そして事前に感謝します。

4

3 に答える 3

2

これは良いようですが、ユーザー-イベント関連付けテーブルを1つに結合し、関連付けの目的（イベント、スタッフ、またはAlt）を示す列をそのテーブルに配置することを検討することをお勧めします。これにより、ほとんどの目的でStaffとAltがEventのスーパーセットと見なされる可能性があるため、UserEventテーブルで説明する重複の必要が事実上なくなります。

このアプローチの利点の1つは、複数のタイプのユーザー-イベントの関連付けが可能になることです。たとえば、イベントのスタッフであるが参加者ではないユーザー、または単なるAltであるユーザーがいる場合などです。このアプローチにより、考えられるすべての組み合わせを列挙する必要がなくなります。さて、あなたのデザインがあなたが特定のユーザー参加タイプのセットしか持つことができないことを明示的に指定しているなら、これはあなたが望まないレベルの分離をもたらすかもしれません。ユーザーがイベントに対して持つ可能性のある参加レベルのセットに明示的な制約を設定することをお勧めします。一方、厳密に指定されたセットがない場合、このシステムでは、参加ロールを簡単に（既存の参加ロールを邪魔することなく）追加できます。

于 2009-06-24T22:20:56.100 に答える
2

私は次のテーブルを持っているでしょう：

User (UserID, firstname, lastname, etc.)
Event (EventID, Name, Date, Location, Capacity, etc.)
EventRegistration (EventRegistrationID, UserID, EventID, ParticipantTypeID, etc.)
ParticipantType (ParticipantTypeID, Name)

ParticipantType.Nameは、「participant」または「staff」のいずれかです。

于 2009-06-24T22:22:12.693 に答える
1

あなたの質問に対する直接的な回答ではありませんが、私が気に入っているサイトは次のとおりです。大量の (そして大量の) サンプル スキーマがあります。私は通常、それを決定的なものとしては使用しませんが (もちろん)、時には、私が考えていなかった何かについてのアイデアを得ることができます.

于 2009-06-24T22:26:59.487 に答える