0

次の構造のテーブルがあります。

event
- id
- date_start
- number_hours
- date_end 
- specialist_id / specialist assigned to this event.

ユーザーは、イベントの開始日と継続時間数を選択します。現在、これらのイベントはすべて非定期的ですが、定期的なイベントの可能性を追加したいと考えています。

どうすれば適切に設計された方法でこれを行うことができますか? このデザインを拡張して、毎週および毎月のイベントだけでなく、毎週日曜日、土曜日、またはその他の定期的なイベントもサポートできるようにしたいと考えています...ありがとう

以下のことを考えていました

イベント

- id
- date_start
- recurring / whether the event is recurring or not
- weekly / (if repeats every 1 week, this will be 1, if repeats every 2 weeks, this number will be 2)
- monthly / (if repeats every 1 month, this will be 1, if repeats every 2 months, this number will be 2)
- last_occurred_date / date the event last occurred (if non-recurring, this equals date_start, if recurring, it does not)
- next_occurred_date / date when the event is supposed to occur next.
- specialist_id / what specialist took this event

したがって、ユーザーが 2012 年 10 月 1 日に毎月繰り返されるイベントを追加すると、次のエントリがテーブルに追加されます。

date_start: 10/1/2012, recurring: 1, weekly: 0, monthly: 1 (it occurs every 1 month), last_occurred_Date: 10/1/2012, next_occurred_date: 11/1/2012)

そして、基本的にすべての定期的なイベントを通過する cron ジョブがあります (ここで、event.recurring = 1 で、新しいイベントが発生するためにイベント テーブルにエントリを追加します)。

したがって、イベントの次の日付は 2012 年 11 月 1 日です。次のエントリが追加されます。

id: 1 date_start: 11/1/2012 recurring: 0

定期的なイベントが行われる日付ごとにエントリを追加する理由は、各イベントにスペシャリストを割り当てる必要があるためです。そのため、スペシャリストは、各イベントにサインアップできるリンクが記載されたメールを受け取ります。

4

1 に答える 1

0

私はイベントのために2つのテーブルを考えており、参加者と再発のために他のいくつかのテーブルを考えています。1つのテーブルはイベント「テンプレート」を保持し、別のテーブルは実際のイベントインスタンスを保持し、場合によっては3番目のテーブルが再発を追跡します。

  • event_defaults
    • id
    • イベント名
    • event_duration（INT秒）
    • 位置
  • default_participants
    • ユーザーID
    • event_defaults_id（event_defaults.idへの外国のキー、決してNULLではない）
    • （user_idとevents_default.idの間のデュアル主キー）
  • event_recurrence
    • event_defaults.idへの外国のキー
    • recurrence_unit（日、週、月、四半期、年のENUM）
    • recurrence_multiplier（反復する日数、週数、月数のINT）
    • 開始日
    • recur_until
  • イベント
    • event_id
    • defaults_id（event_defaults.idへの外国のキー、おそらくNULL）
    • 名前
    • start_time（タイムスタンプ）
    • end_time（タイムスタンプ）
    • 位置
  • 参加者
    • ユーザーID
    • event_id（events.idへの外部キー）
    • （user_idとevents.idの間のデュアル主キー）

アイデアは、定期的なイベント用であり、event_defaultsテーブルにエントリを作成し、 event_recurrenceに定期的な情報を作成します。次に、すべてのテンプレートのインスタンスをイベントの実際のイベントとして作成します。その後、ユーザーは各イベントに必要な参加者を定義できます（デフォルト）。すべてのワンタイムイベントは、event_defaults.idへのforiegnキーがNULLであるイベントに直接挿入されます。

イベントの繰り返しがなくなったら、event_defaultsのエントリを削除して、イベントで発生したイベントの記録を保持できます。何日も経ってからこれらの人を整理したり、別のテーブルにアーカイブしたり、期限切れのイベント用にイベントテーブルのパーティションを維持したりすることができます。

テンプレートと各イベントの実際のインスタンスを別々に保つことで、テンプレートを同じに保ちながら個々のイベントを変更できるのは素晴らしいことです。たとえば、今週、オフィスの会議室ではなく、あるレストランでウィークリーオフィスミーティングが開催されているとします。これで、毎週のテンプレートを変更せずに、イベント内のイベントの適切なインスタンスの場所を更新できます。

さらに、イベントごとにデフォルトのスペシャリストを割り当てることができ、何らかの理由で他のスペシャリストに切り替える必要がある場合は、テンプレートではなく、個々のイベントインスタンスを編集するだけです。

さらに、cronジョブは、最大recur_untilまたは.... 10年間、新しいイベントを作成できますか？あなたが決めるどんな任意の間隔でも。時間の終わりまで定期的なイベントのインスタンスを作成することはお勧めできません。

于 2012-10-01T16:00:39.857 に答える