2

空き状況カレンダーを作成しています。予約可能なイベントには、予約に使用できる 1 つ以上のリソースがあり、イベントは定期的であり、定期的なイベントの 1 つのインスタンスの編集などの基本的な機能 (たとえば、Google カレンダーなど) を持つことができます。カレンダーは予約も保存できる必要があります。

例: 2014 年末まで、毎週月曜日の 10:00 に、ユニット A には 2 つのリソースが利用可能ですが、24/6 の月曜日には利用できません。先週の月曜日、UserX と UserY はそのイベントで予約されましたが、UserX は現れませんでした。

定期的なイベントの設計パターンをいくつか見てきましたが、定期的なイベントと個々のイベントへの詳細の添付の両方を処理するための適切でエレガントな方法を実際に見つけることができません。

イベントと繰り返しを Event に格納するモデリングをいくつか行った後、個々のイベントごとに EventDetails-instance を作成する必要があります。

class Event {

    Date start
    Date end

    boolean isRecurring
    EventRecurType recurType // DAILY, WEEKLY ...
    Integer recurInterval = 1
    Date recurEnd
    Integer recurCount
    List<EventDetails> eventDetails // Id, start, end, BookingDetails et.c.
}

これを行うためのより良い方法があると確信しています、私を助けてもらえますか？

4

1 に答える 1

1

通常、データベース設計では、コンポーネントを分離し、それらを異なるキーに関連付けます。それに関する基本的なことは知っていると思います。

したがって、私の最初の考えは次のようになります。

イベント、イベントの詳細を含むテーブル - eid (イベント ID)

ユーザー、ユーザーの詳細を含むテーブル - および uid (ユーザー ID)

繰り返し、繰り返しイベントを持つテーブル、eid と uid のキー、繰り返しパターンなどの他の関連情報 (私は列挙型を使用します)。

頭痛の種になるので、すべてを 1 つの巨大なテーブルに入れたくはありません。関心を分離することで、後でスケーリングできます。

ルックアップは単純な結合であり、日付やユーザーなどのデータのルックアップに使用されるフィールドにインデックスを配置して、検索を高速化しますが、挿入が遅くなるため、夢中にならないでください。

うまくいけば、これが役に立ちます。

于 2013-06-22T15:14:16.123 に答える