從一個 OLTP 系統到另一個系統的數據 ETL 的最佳實踐是什麼，第 2 部分？
好的，我最初提出了一個問題，稱為“從一個 OLTP 系統到另一個系統的數據 ETL 的最佳實踐是什麼？” . 到目前為止，您可能從我的大多數問題中可以看出，他們必須處理 ETL。這是因為作為一名開發人員，我正在向那些比我更接近數據庫的人尋求知識。此外，我不想在我最初提出的問題上弄得一團糟，因為我確實得到了這個問題的答案。因此，我的“第 2 部分”。
話雖如此，我可能會在架構師和其他關鍵利益相關者的每個高級設計審查中使用自定義 Java 程式碼。現在我開始討論 ETL 過程的詳細設計。我想知道在目標數據庫中插入/更新數據的最佳方式是什麼？
我應該只使用標準程式碼循環技術並在處理它們時逐條插入/更新記錄嗎？還是最好生成一個包含所有更改的 .sql 平面文件，然後在最後執行該文件？由於我需要為我的 ETL 獲取鍵映射數據庫的目標數據庫記錄鍵，我不確定第二個選擇是不是最好的主意？
有任何想法嗎？指導方針？幫助？各自的優缺點是什麼？是否有任何要求（功能性或非功能性）可以幫助您決定哪個選項？任何幫助我了解我所面臨的問題都值得讚賞。
關係數據庫的人總是喜歡以“集合”的方式思考，但有些任務就是不能這樣工作。使用 ETL，由於無法繞過物理磁碟來實際寫入數據，因此您只想盡可能減少與每個單獨查詢相關的成本。
為 MSSQL 說話。如果您使用“參數化”查詢。循環程式碼並以這種方式更新應該沒問題。這樣做的原因是，通過使用參數化查詢，SQL 引擎可以記憶體一個查詢計劃以供循環的每次迭代使用，並避免每次從頭開始的成本。
如果您不熟悉該術語，請使用 Google 參數化查詢。用 Java 術語來說，您還可以搜尋 Prepared Statements。
我在上一篇文章中說“應該沒問題”……假設您要重複執行的查詢盡可能寫得好且高效。
如果您能夠分析將要重複執行的範例查詢並找出它的結果查詢計劃是什麼。您可能會發現可以關閉一些不必要的索引以提高更新性能。
或者，另一方面，如果您的更新包含導致對相關表進行表掃描的邏輯，您可能會發現添加索引將大大提高更新的性能。