54

カレンダーアプリケーションを書きたいです。DB スキーマの作業に支障をきたすのは、本当に繰り返し発生する項目です。これを整理する方法について、いくつかの意見をいただければ幸いです。

ユーザーがイベントを作成し、それが月曜日に全員に繰り返されることを入力した場合はどうなるでしょうか? それをすべてデータベースに保存するにはどうすればよいでしょうか。無限のイベントを作成することはできません。すべてのイベントがどこに行くのかを計算できるように、関連情報を保持するテーブルをそこに置くだけですか? もしそうなら、ユーザーがカレンダーの新しい部分を表示するたびにそれらを計算する必要があります。月ごとにページをめくっていても、定期的なアイテムが大量にある場合はどうなるでしょうか?

また、スキーマは、ユーザーがアイテムをクリックして、シーケンス内のすべてのアイテムではなく「シーケンス内のこのアイテムを編集してください」と言ったときに処理する必要があります。次に、シーケンスから 1 つの項目を分割しますか?

更新 1

私はiCalをまったく見ていません。明確にするために、定期的なアイテムを計算できる情報を保存し、シーケンスと異なるものを分割することは、それを転送できるように保存するための優れた方法だと思います. しかし、アプリケーションでは、これは遅すぎて、いたるところで日付計算を行うことができないと思います。

4

7 に答える 7

24

私は同じ問題に苦しんでおり、実際には上記で提案された「キャッシュテーブル」のアイデアをいじっていましたが、まだ表されていないように見える代替案(ここで提案)に出くわしました。

すべてのイベントを含むテーブルを作成する

EventID (primary key)
Description
StartDate
PeriodType - days, weeks, months, years
PeriodFreq - # of days, weeks, etc between events
EndDate
... other attributes that can be modified

次に、これらのイベントの例外の表を追加します。このテーブルは、イベント テーブルにマップされる EventID とインスタンス ID で構成される複合キーを使用して、シリーズ内の特定のイベントを選択します。

EventID (key)
InstanceID (key)
InstanceDate - the modified date of the exception 
IsCancelled - a flag to skip this date when traversing the series
... other attributes that can be modified

イベントテーブルを正規化したままにしているようで、例外を処理するためにシリーズを分割することを避けています。

于 2012-05-19T11:05:07.490 に答える
3

次の X 日分のイベントを事前に計算する「キャッシュ」テーブルを使用して、2 つの世界を橋渡しできますか?

したがって、3 つのテーブル:

recurring_event_specs
one_time_events
cached_recurring_events

今日から X 日以内のカレンダーの任意の部分について、クエリは UNIONone_time_eventsとcached_recurring_events.

そうすれば、ユーザーが X 日以上先のカレンダーの一部を見ようとした場合にのみ、その場で日付計算を行う必要があります。通常の使用の大部分をカバーする正気のXを見つけることができると思います.

cached_recurring_eventsユーザーが新しい定期的なイベントを追加するたびに、テーブルを更新する必要があります。また、cron ジョブ/スケジュールされたタスクによって、おそらく 1 日に 1 回オフラインで更新する必要があります。ただし、新しい定期的なイベントが作成されていない日のみ。

于 2009-06-03T21:24:57.800 に答える
3

このカレンダー アプリケーションのデータベースとして Google カレンダーを使用して、Google カレンダーの APIを使用してカレンダー イベントを保存および取得してみませんか?

Calendar API は、明示的な HTTP 呼び出しを介してアクセスできる REST API です。この API は、Google カレンダーの Web インターフェースで利用できるほとんどの機能を公開しているため、カレンダー アプリケーションは、Google カレンダーと同じくらい多くの機能を利用できます (多くの機能!!!)。

アプリケーションは、Google API 用に OAuth 2.0 を実装するだけで済みます。これは、Auth0などのシングル サインオン サービスを使用して適切なアクセス トークンを提供することで簡単に実現できます。次に、カレンダー アプリケーションでこれらのトークンを Calendar API と組み合わせて使用​​し、カレンダー イベントを JSON 形式でシームレスに保存および取得できます。

ユーザーは自分の「新しいカレンダー」内でイベントを作成します。このカレンダーは、このアプリケーション専用の Gmail アカウント (アプリケーションの Gmail アカウント) の形式で共有されます。

基本的に、Google カレンダーはデータベースになります。これにより、アプリケーションの gmail アカウントにアプリケーションのすべてのイベントを保存できるだけでなく、これらのイベントを直感的なインターフェイスで表示および編集することもできます。

于 2016-07-05T10:31:44.787 に答える
1

これを行う最善の方法は、標準ベースの繰り返しパターン文字列 (iCal) を保存し、単一のイベントの場合は空白のままにすることです。繰り返しパターンを解析し、UI 要素にバインドできるイベント オブジェクトを作成できる API がいくつかあります。..発生をデータベースに保存する必要はなく、最初のイベント (発生) のみを保存する必要があります。

于 2010-09-16T05:33:59.353 に答える