これは私の最後の質問に似ていますが、実際には問題に要約されます。
タスクをスケジュールするシステムを設計しています。ほとんどの場合、繰り返し発生するタスク。たとえば、ユーザーは「床を掃除する」を毎週月曜日、水曜日、金曜日に実行するようにスケジュールできます。
スケジュールから、タスクが特定の日に実行される予定であるかどうかを判断できます。最も重要なのは、タスクが当日に実行される予定であるかどうかを判断できることです。次に、この現在のタスクのリストをワーカーに表示する必要があります（そしてそれをサイト周辺の受話器に送信します）。
次に、ユーザーは、タスクを開始したこと（したがって、状態Task-Startedが必要）と、タスクを完了したとき（Task-Worked）を示します。ワーカーが仕事をうまく行っていない場合、タスクを検査している誰かがタスクを「失敗」して、終了状態のタスク失敗になります。タスクには他の状態もいくつかある可能性がありますが、この質問の範囲にはそれで十分です。
私が疑問に思っているのは、データベースに各タスクオカレンスのインスタンスを作成して、タスクのその特定のインスタンスに対する状態を保存できるようにする必要があるかどうかです。別の見方をすると、データベースに「Due」の初期状態、または「Due-Today」と実際のDateTime（または少なくともOpportunityウィンドウのDateTime）を作成していると思います。タスクを実行します）。
ただし、この状態は、「今日の」タスクリストを生成する場所であるため、いつでも導出できます。したがって、正規化エラーのように感じます。とにかく導出できるデータを繰り返しているように感じます。
長所：
これにより、生成された「期限」タスクに正確な日時を設定できるため、将来の日にのみ影響するスケジュールの変更からタスクを保護できます（ただし、Schedule-Historyテーブルを使用すると、古いデータを取得できます）。
その日に何か特別なことが起こった場合に備えて、その特定の日のスケジュールを微調整することができます。
それは、それを導出するのではなく、データベースに正式な状態を作成します（私はそれを作り上げましたか？）。
短所：
- これらのインスタンスを生成するには、バックグラウンドプロセスが必要になります（または、表示方法に応じて、「Due」または「Due-Today」状態を生成します）。
私の問題はこれに帰着すると思います：
1）スケジュールが正確な日時のリストである場合、各エントリはタスク自体を記述しているため、問題はありません。それは事実です：この日時でのこのタスク。そして、そのタスクが完了すると、それに対する事実を保存します。
2）ただし、定期的なスケジュールでは、実際の発生を説明するのではなく、各タスクをいつ行うべきかを説明するだけです。
それが理にかなっていることを願っています。考え？