イベントの再発ごとに、ある地平線に向かってエントリを作成するだけです。ただし、ホライズン日付を過ぎてスキャンした場合に日付を予測するために使用できる別のテーブルが必要になることを意味します。つまり、繰り返されるイベント（1月1日、1月8日、1月15日、...から12月）ごとに1つのレコードを含むイベントテーブルと、将来の年をシードするために使用できる各レコードを含むテーブルが必要になります（開始日付：1月1日、繰り返し：7、から：2011）。これにより、2012年の初めに（またはユーザーが2012年以降の月の表示を要求するとすぐに）、将来のイベントを生成できます。
これには2つの大きな欠点があります：
- データベースには1年間のデータがあります。ただし、1年分のデータを追加するとパフォーマンスが低下する場合は、システムの能力が不足している可能性があります。 （カレンダーアプリが何年にもわたる日付を処理できることが要件のようです）
- 事象の地平線の終わりに、定期的なイベントの将来の日付を生成する必要があります。
短所を上回る長所（IMO）：
- カレンダーを表示するときの計算が簡単になります。上記のTimの方法を使用して、ユーザーが2011年12月18日を読み込んだ場合、その日にどの定期的なイベントを配置する必要があるかをどのように計算しますか？日付を表示するたびに、繰り返し発生するすべてのイベントをループする必要があります。トレードオフは不利な点＃1です。これは、これらの計算をやり直さなければならないよりも優れた解決策だと思います。
- イベントの特定のインスタンスを編集できます。ティムの方法を使用して、休日に会議が発生し、ユーザーがそれを前日に変更した場合、どのようにそれを行うのでしょうか。ここで説明するイベントごとに1つのエントリの方法を使用すると、イベントのレコードを変更するだけで、カレンダー内の単一のオカレンスを簡単に移動できます。