我正在設計一個需要存儲事務時間和有效時間的數據庫，而且我正在努力如何有效地存儲數據以及是否完全時間規範化屬性。例如，我有一個具有以下屬性的表格Client：ID，Name，ClientType（例如公司），RelationshipType（例如客戶端，潛在客戶），RelationshipStatus（例如Active，Inactive，Closed）。 ClientType，RelationshipType和RelationshipStatus是時變字段。性能是一個問題，因爲這些信息將與傳統系統中的大型數據集關聯。同時，數據庫結構需要易於維護和修改。 我打算將審計跟蹤和時間點歷史分解爲單獨的表格，但我正在努力解決如何最好地完成此操作。雙時鐘數據庫設計問題
的一些想法，我有：
1）三個表：客戶，ClientHist和ClientAudit。客戶端將包含當前狀態。 ClientHist將包含任何先前有效的狀態，並且ClientAudit將用於審計目的。爲了便於討論，讓我們忘掉ClientAudit並假設用戶永遠不會犯數據輸入錯誤。這樣做，我有兩種方法可以更新數據。首先，我總是可以要求用戶提供一個生效日期並將記錄保存到ClientHist中，這會導致每次字段更改時將記錄寫入ClientHist。或者，我只能要求用戶在時變屬性之一（即ClientType，RelationshipType，RelationshipStatus）發生變化時提供生效日期。只有當時變屬性被改變時，這將導致記錄被寫入到ClientHist。
2）我可以將時變屬性分成一個或多個表格。如果我走這條路線，我會把所有三個表放在一個表中，還是創建兩個表（一個用於RelationshipType和RelationshipStatus，另一個用於ClientType）。爲時變屬性創建多個表的確顯着增加了數據庫設計的複雜性。每張表也都有關聯的審計表。
有什麼想法？
感謝您的重播！ ClientType很少會改變，如果有的話。但是，如果確實如此，我們需要知道它在某個特定點上的情況。客戶關係類型和狀態將更加頻繁地變化，但並不常見。另一個想法是將RelationshipType和RelationshipStatus分解爲單獨的表格。這會稍微容易維護。 – LeaK
是的，我同意讓用戶輸入日期。但是他們沒有選擇，因爲他們想要歷史地追蹤這些數據。我的問題是如何使數據輸入直觀。他們將不得不在更新不正確的信息和實際的數據更改之間進行思考。使用生效日期是否改變，但這不是100％，因爲它們可能只是糾正了一個不好的生效日期。 – LeaK
爲了使它更直觀，您可以設計一些事情：每當用戶輸入重要數據時，他們知道/被告知變更將在一天結束時生效（即第二天啓動）？也許在下一個工作周（星期一）開始？如果生效日期總是以相同的方式計算，他們不必擔心。如果他們在之前的變更變爲「主動」之前輸入了後續變更，那麼（按照定義？）早先和現在被覆蓋的項目將是「不正確的信息」。 –