這是一個規範化錯誤？

Question

這與我最後一個問題類似，但它更多地歸結爲這個問題。

我正在設計一個系統來安排任務;大多數時候重複執行的任務。例如，用戶可以安排「掃地」發生在每週的星期一，星期三和星期五。

我可以從日程安排中瞭解某項任務是否會在某一天完成，最重要的是，我可以判斷是否應該在當天完成任務。然後，我必須向工作人員顯示當前任務列表（並將其發送給站點周圍的手持設備）。

然後用戶指出他們已經開始了任務（所以我們需要一個狀態任務啓動）並且他們完成了一個任務（Task-Worked）。如果工作人員沒有很好地完成這項工作，檢查任務的人可以「失敗」，進入結束狀態任務失敗。任務也可以有其他一些狀態，但這對於這個問題的範圍應該是足夠的。

什麼我不知道是我是否應該創建數據庫中的每個任務發生的實例，從而使我能夠存儲狀態對任務的特定實例。我想另一種看待它的方式是我在數據庫中創建「Due」的初始狀態，或者「Due-Today」以及它到期的實際DateTime（或者至少Window of Opportunity的DateTime做任務）。

但是 - 這個狀態總是可以得到因爲這是我從那裏生成「今天」任務列表的地方，所以它感覺像是一個規範化錯誤 - 感覺就像我重複可以派生的數據無論如何。

優點：

• 這將允許產生「由於」任務有一個確切的日期，時間，從而從更改時間表，只會影響以後的日子裏屏蔽它（雖然，批准我時刻表歷史記錄表格允許我查看舊數據）。

• 該特定日子的日程安排可能會調整，以防萬一那天發生了一些非同尋常的事情。

• 它在數據庫中創建一個正式的狀態，而不是派生它（我剛剛做出來了嗎？）。

缺點：

• 這將需要一個後臺進程產生這些實例（或產生「到期」，或「由於-今天」的狀態，這取決於你如何看待它）。

我想我的問題歸結爲：

1）如果計劃只是一個確切的日期 - 時間的列表，每個條目描述了任務本身就沒有問題。這是事實：這個任務在這個日期時間。一旦這個任務完成，我們就將這個事實存儲起來。

2）然而，循環調度只是描述每個任務的時間，而不是描述實際發生的情況。

我希望這是有道理的。思考？

Answer 1

做單獨的「任務」和「任務實例」，但不要在任務到期時生成新的實例。

在啓動時生成它（並將結束時間和成功狀態保留爲NULL）。當任務實例完成時，用具體值替換這些NULL。

因此，無需後臺進程，但你總能確定何時：

• 由於任務不啓動（沒有在實例錶行）
• 或啓動的任務還沒有完成（ NULL結束時間）
• 或完成的任務如何成功（通過檢查結束時間爲非NULL的任務實例的成功狀態）。

Answer 2

我想這個模型作爲任務調度，像這幾天的任務發生在當它是未來由於這將包含的信息。

作爲每天的後臺工作，您將查看時間表並確定它們今天是否發生。如果是這樣，您將創建一個任務記錄，並更新下一個到期日期。下一個截止日期是反規範化，但我認爲它使生活更容易。這取決於調度邏輯的複雜程度以及您擁有的數據量。

任務表是任務計劃的子代。任務表將包含到期日期，狀態，分配給的等等。同時你將這些任務發送給手機（當第一個成功完成時，我會在第二個任務中啓動）。