我已經在幾個應用程序上工作過，並與其他開發人員討論過有關數據倉庫的幾個細節。如何遞增填充數據倉庫？
我看到的主要問題是關於操作數據存儲中的更改數據檢測（CDC）。 更新和硬刪除顯然可能很難在操作數據存儲中檢測到。
可以通過在EVERY表上插入觸發器來處理更新，該觸發器會使用當前時間戳自動更新updated_at列。儘管刪除更困難 - 一種解決方法是在觸發器中更新一個刪除了id的審計表，一張表和一個時間戳。
使用觸發器似乎是最合理的方式來執行更改數據檢測，但我已經看到的另一個選項是解析數據庫事務日誌文件，雖然這可能會更難以更新操作數據存儲數據庫。
我的問題是，人們通常如何處理這個問題？我已經做了相當多的研究，看起來好像很多做數據倉庫的公司正在推出他們自己的次優解決方案。
我發現避免與CDC相關的問題的另一種解決方案是每隔一段時間簡單重建一次ENTIRE（或與源數據相關的部分）數據倉庫，這將確保所有數據是最新的並且在操作數據存儲上執行CDC的代碼中沒有任何錯誤。
這是我通常處理更新和刪除的方式。
更新源系統
某些DBMS的提供了一個列，其中，如果添加到所有的表，提供了一個唯一的標識符，始終是增加倉庫。 SQL Server具有TIMESTAMP列。 Oracle提供了ora_rowscn僞列，這在塊級別上很好。
雖然我還沒有使用它，Postgres有xmin僞列，我相信它可以以類似的方式使用。有一些擔心，但我認爲數據倉庫更改跟蹤的目的，它可能會伎倆。
更新觸發器在源系統中更新最後修改日期是另一種選擇。保持這個日期的精確度非常高，以便在執行提取操作時正在運行ODS上的大量更新時減少「缺失」記錄的風險。
刪除在源系統
至於刪除的記錄，我的優選方案是，以確保所有的源表的主鍵（優選一列，儘管多是可行的）。我每天將該列的全部內容提取到階段表中，然後確定目標表中與源相比「丟失」的行，更新「源刪除」標誌或目標記錄上的某些內容。我通常只對維度表執行此操作，因爲事實表應該保留歷史記錄，即使原始事務已經結束。
我認爲不應該刪除或更新正確設計的數據倉庫中的事實表，只能插入。然後，通過時間戳或通過一些順序ID來捕獲插入應該是微不足道的。
我在說什麼時候有人刪除生產數據庫中的記錄，而不是數據倉庫中的記錄。 –
除非事實表是一個累積的快照事實......那麼更新每天都會發生。 –
作爲postgresql用戶和開發人員，您所描述的使用觸發器是--IMHO--最好的方法。讓數據庫完成它設計的任務：管理和保護您的數據。使用更新日期和使用刪除日期處理的邏輯刪除可以更輕鬆地提供事務的歷史記錄。使用低負載時間將「刪除」的數據移動到歷史表有助於保持生產表的可管理性。
作爲附錄：解析ODS日誌文件通常是主要ETL供應商中的CDC工具所做的工作。解析日誌並不是一件容易的事，我會推薦我提到的觸發器或其他方法。 –
很好的回答ñ西！ –