3
關於在數據庫中存儲歷史記錄，使用DateEnd（Ex。1）還是Duration（Ex。2）更好？或者請隨意甚至建議另一種最有效的方法。將歷史存儲在數據庫中
如果證明是正確的方法，我還應該對其中一個示例做出其他更改嗎？ DB正在使用的是MySQL，儘管我不認爲它對這裏的方法有影響。
A
回答
1
對此有兩種觀點 - 首先，業務領域是什麼？在您的示例中，您使用了「訂閱」 - 這些通常以「每月」，「每週」等形式出售。所有其他條件相同的情況下，我希望我的數據庫儘可能符合業務概念。你甚至可以創建一個「subscription_type」表，並從類型中得出描述的持續時間。
這經常與需要執行的數據庫衝突。從這個角度來看，我會研究最常見的查詢將會發生什麼，並且看看您是否可以使用盡可能少的類型轉換或計算來進行數據庫設計。例如，如果您可以要求dateEnd < targetDate，而不是通過在開始日期中添加持續時間來計算日期，那麼查找訂閱在給定日期到期的所有記錄會更容易（也可能更快）。
0
我將存儲，而不是時間的結束日期。您可以根據需要計算持續時間。似乎更有意義的是存儲測量點而不是測量。
+0
如果使用持續時間，實際上是在丟失信息 - 從測量點到測量始終是可能的，但通常不可能從測量重新創建測量點。 – 2011-03-20 17:44:12
0
派生值（如持續時間）不需要存儲在數據庫中。
在某些情況下，您捕獲行的歷史記錄的方法將會有效，但要真正捕獲所有行的所有更改，您可能需要另一個表，類似subscription_hist，它將通過插入和更新觸發器訂閱。那麼你將不得不跟蹤last_modified_date和last_person_changed_by。其他一切都可以派生出來。這樣你可以看到隨着時間的推移發生了什麼。我沒有任何圖片需要澄清，但是如果仔細實施，這種方法可以實現數據的完全時間點恢復以及維護歷史信息。
+0
當您引入另一個如subscription_hist時，您提到的不僅僅是在數據庫中創建重複項？或者你是否在金融體系中提出某種交易表格？ – swisscheese 2011-03-20 03:09:15
1
如果您有開始日期和結束日期，您可以始終（或應該始終能夠）計算持續時間。如果您有開始日期和持續時間，您可以始終（或應該始終能夠）計算結束日期。
您也可以記錄所有三個並強制執行行約束，以使它們不能「不匹配」。
但是，「結束日期」數據的一種非常常見的用法是過濾出「不是當前」行：類似於WHERE END_DATE> CURRENTSYSTEMDATE（）。如果你有這種用法，那麼可能不建議「結束」結束日期。
現在你讓我思考更多。我將不得不查看一些事情，看看SubscriptionType表是否可以滿足我的需求。「這經常與您的數據庫執行需求衝突」是因爲您對第一段的迴應，因此我應該遠離這樣做？這裏的重要性在於跟蹤結束日期，讓用戶知道什麼時候需要重新啓動。例如30天（任何增量/秒）通知並記錄訪問限制的過期賬戶。當然，其他內部問題也會完成，但是要考慮到同樣的基本概念。 – swisscheese 2011-03-22 04:14:24
是的，性能問題往往與模擬業務領域的願望相沖突。就你而言，除非你有數百萬用戶，否則我不會認爲這是一個重大問題。如果你想創建提醒等，我會考慮將它們放入一個「提醒」表中，並具有狀態以跟蹤它們是否已被採取行動 - 如果有必要，你可以保持跟蹤甚至是提醒，或者在人們更有可能迴應的日子裏發送出去（週末可能比周一晚）。 – 2011-03-22 09:36:47