0

序章

こんにちは。今後のプロジェクトで定期的に発生するイベントの適切な解決策を見つけるために、かなりの時間をかけて調査しました。以前にイベントや定期的なイベントを扱ったことがありますが、気に入ったソリューションを見つけたり開発したりしたことはありません。そこで、繰り返しを処理するために CakePHP 用のプラグインを構築することを考えています。

このプラグイン/クラスを使用したいユースケースが 2 つあります。

  1. 定期的なイベント - カレンダーまたはリスト ビュー
  2. 定期的な支払い - ゲートウェイの定期的な支払いを使用したくない場合や、今後の支払いの通知を行いたい場合などがあります。

他にも多くのユースケースがあると確信していますが、これらは私が最も頻繁に遭遇する2つです。実際、データベーススキーマと基本的なソースコードは、さまざまなユースケース間で完全に再利用可能ではないにしても、似ているはずです.

そのため、定期的なイベントに使用する適切なデータベース スキーマを決定するのに助けが必要です。私には 2 つのアイデアがあり、それぞれに長所と短所があると思いますが、柔軟性、保守性、およびパフォーマンスのための最適な全体的なアプローチに落ち着く必要があります。

したがって、どちらのソリューションでも、イベントを追加、編集、削除、および一覧表示できる必要があります。イベントが発生するすべての日または特定の日を編集または削除するオプションを使用して、定期的なイベントを編集できるようにしたいと考えています。Googleカレンダーに似た繰り返しルール/オプションが欲しいです。毎日、毎週、毎月、毎年などのオプション。

最初のアイデア

定期的なイベントを格納するための events と呼ばれる 1 つのテーブル。このアプローチでは、繰り返しオプションを解析し、本質的にループして、繰り返しオプションに基づいて個別のイベントを作成する必要があります。たとえば、開始日が 2012 年 1 月 1 日、終了日が 2012 年 12 月 31 日の「Weekly Meeting」というイベントを作成したい場合、イベント テーブルに 52 レコードを作成します。このアプローチは、編集と削除の管理が難しく、イベントの保存に時間がかかると思いますが、データのリストは、日付範囲を照会するだけで簡単になるはずです。そのイベントの繰り返しを変更する必要がある場合は、悪夢になる可能性があります。

CREATE TABLE `events` (                                                               
      `id` int(10) unsigned NOT NULL AUTO_INCREMENT,                                      
      `parent_id` int(10) unsigned NOT NULL,                                              
      `start_date` datetime NOT NULL,                                                     
      `end_date` datetime NOT NULL,                                                       
      `title` varchar(150) CHARACTER SET latin1 NOT NULL,                                 
      `description` text CHARACTER SET latin1,                                            
      `created` datetime NOT NULL,                                                        
      `modified` datetime NOT NULL,                                                       
      PRIMARY KEY (`id`)                                                                  
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8

第二のアイデア

繰り返しを処理するために複数のテーブルを用意します。これにより、編集と削除の問題が解消され、保存も高速になるはずですが、イベントを取得するためのデータのクエリは複雑になり (mysql クエリは複雑になると考えられます)、遅くなると思います。このシステムは、イベントの書き込みよりもはるかに多くの読み取りを行うことになります。しかし、再利用できる一般的なソリューションが必要です。キャッシングを使用して読み取りを改善することもできるので、大きな懸念事項ではありません。52 エントリの代わりに上記の例を使用すると、イベント テーブルには 1 つしかありません。

正確なスキーマについて不明な点はありますか?

あなたの助けとアイデアを前もってありがとう！定期的なイベントを他の人がどのように処理しているかを把握したい。

4

1 に答える 1

1 
CREATE TABLE `events` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `parent_id` int(10) unsigned NOT NULL,
    `title` varchar(150) CHARACTER SET latin1 NOT NULL,
    `description` text CHARACTER SET latin1,
    /** Some fields about how the recurring is applied  **/
   `created` datetime NOT NULL,
   `modified` datetime NOT NULL,
   PRIMARY KEY (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8

CREATE TABLE `event_occurrences` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `event_id` int(10) unsigned NOT NULL,
    `date` DATE NOT NULL,
   PRIMARY KEY (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8

繰り返しの詳細、開始または終了フィールドが変更されていない場合、event_occurrences をいじる必要はありません。これらの詳細のいずれかを変更してDELETE FROM event_occurrences WHERE event_id=?から、特定のイベント ID の event_occurrences を生成するメソッドを用意します。作成と変更には同じ方法を使用できます。

于 2012-07-27T17:42:49.510 に答える