在 OLTP for Data Warehouse 上擷取更改的最佳方法：創建/更新列或 CDC
將 ETL 數據移入數據倉庫的更好方法是什麼？在 OLTP 應用程序或更改數據擷取 (CDC) 上創建/更新日期？
鑑於系統允許使用這兩者並且資源不是問題，我認為 CDC 更可取。有時，我看到軟體應用程序/開發人員在“創建/更新”列不起作用的地方犯了錯誤。只是希望有人驗證想法。
也對 Kimball 提到的內容感到好奇，他似乎更喜歡這裡的 CDC？
https://www.kimballgroup.com/2007/10/subsystems-of-etl-revisited/
https://www.kimballgroup.com/2009/10/six-key-decisions-for-etl-architectures/
你已經回答了你自己的問題！
使用供應商的解決方案總是比“自己動手”要好…有多少人會測試您的“自製解決方案”？他們會遇到多少極端情況？
我願意在這裡冒險並聲明，也許，只是也許，它可能在您的客戶群沒有 Microsoft SQL Server 的客戶群那麼大的可能性範圍內……微軟確實有有數百萬人測試他們的解決方案 - 很可能任何錯誤都會被修補 PDQ！
這是我之前給出的答案中的引述——原始引述來自寫這些書的喬納森·劉易斯（ Jonathan Lewis ） ！乍一看沒有相關性，但相關性有望變得明顯！
第 10 章：設計災難，喬納森·劉易斯 (Jonathan Lewis)
更多戰爭故事，獻給第 8 章的粉絲！“現在準備好閱讀有關‘世界上最糟糕的甲骨文項目’的所有內容。”——喬納森·劉易斯。
本章描述了開發 Oracle 數據庫應用程序中一些最常見的錯誤。你肯定會認出其中一些，因為有很多人固執地堅持某些信念。我知道當我遇到以下常見論點時，我喜歡提出他的幾個觀點：
我們希望我們的應用程序是“數據庫獨立的”。
我們將在應用程序級別檢查數據完整性，而不是利用 Oracle 的約束檢查能力。
我們想為我們的主鍵使用序列。
只需將第 2 項中的“實施變更數據擷取”替換為“檢查數據完整性”即可。
我懇求你想想你自己、你的同事（他們會在你退休很久之後收拾爛攤子！）、你的公司（如果他們是一個體面的雇主）和你的客戶（如果你關心他們的話）。
離開鍵盤，認真思考這個問題，然後想出我正在輕輕引導你的答案！:-)
**$$ EDIT $$：**回應 OP 評論中提出的觀點。
不，行業不是“換位思考”！NoSQL 是一系列不同類型的妥協，解決了一些問題，同時創造了一整套新問題！NoSQL 仍然是利基市場，並將永遠如此。見這篇文章。許多 NoSQL 供應商都在爭先恐後地將 a) SQL 介面放在他們的產品上（參見 Google 的 Spanner/F1 系統）和 b) 實現 ACID 語義——誰想要不正確的銀行餘額 (BASE)？
你被一輛大車的車輪聲穿過城鎮的聲音和那些跳上車的人的喧鬧聲震聾了。查看 Michael Stronebraker 關於該主題的著作 - 一位真正的數據庫先驅，並且在他最新的 NewSQL 演出 VoltDB 中仍然很強大！
看看未來的行動將在哪裡 - 它將與像 Spanner 這樣的系統（我在大學項目中使用的兩個是CockroachDB和TitaniumDB，還檢查 YugaByte 和 ActorDB），雖然仍然有點“原始”，它們具有符合 ACID 的架構，同時回答了 NoSQL 人群的許多問題！
至於關於 Azure 數據倉庫和（某些）沒有 s 的 AWS 系統的
FOREIGN KEY評論——我會賭一美元給一個甜甜圈，這些數據來自有FOREIGN KEYs 的系統。那些使用它們的人故意選擇（可能）在數據完整性上妥協，以換取他們將在這些 DW 中獲得的速度折衷！