應該使用什麼模型/模式來處理多個數據源？

Question

作爲電子商務系統的一部分，我需要設計和實現各種黑匣子。這需要接受來自各種內部和外部數據源（即，網站，外聯網，雅虎商店，亞馬遜xml提要等）的客戶和訂單，並插入/更新後端系統。 api的插入/更新客戶和訂單數據適用於網站並且運行良好。現在我們需要添加處理來自其他數據源的訂單的功能。

我一直傾向於提供者模型（每個數據源的一個提供者），並使用它將數據標準化到sql server表中，然後調用api來實際添加客戶和下訂單。我應該考慮其他模型或模式嗎？你以前是否處理過這個問題？你是如何解決這個問題的？有什麼資源（文章，書籍，項目等）我應該看看？

Answer 1

您可能會發現一個ETL（提取，轉換，加載）工具會讓你的生活不是試圖解決代碼：

• SSIS（SQL Server集成服務）
• ODI您的問題更容易（ Oracle數據集成）
• Informatica PowerCenter
• Many others

這些是專門爲您描述的數據加載工作類型而設計的。

編輯

雖然我仍然認爲，一個ETL工具將最好地滿足您的需求，如果你堅持在代碼中這樣做，你應該想想實現ETL的圖案。原因在於ETL是從各種來源加載數據的完善的最佳實踐。您應該花一些時間來研究ETL是如何實施的。

在基本級別上，應該有三個圖層：提取圖層，轉換圖層和加載圖層。

提取圖層應負責從源檢索數據。在這一點上，不應該擔心數據的形狀。爲了保持圖層清潔，您應該只實現在這裏「獲取」數據的代碼。擔心在轉換層中形成它。

轉換圖層應負責從各種來源提取數據並將其轉換爲目標形狀。 ETL工具通過將數據視爲管道來非常高效地完成此操作。這些可以拆分和並行化。你可能沒有時間或資源來做到這一點。另一種選擇可能是將數據加載到登臺表（數據的規範化程度較低的表示）。

加載圖層將轉換後的數據（在上述情況下從暫存表中取出）加載到最終目標位置。

這足以分離您的圖層，以便您可以保護自己免受未來更改。但請記住，你真的只是在做ETL工具爲你開箱即可。

Answer 2

如前所述，除非您能夠像EDI或Web服務一樣標準化訂單前臺的方式，否則ETL可能是一種行之有效的方法。

使用ETL工具從源代碼（電子郵件，FTP文件等）轉換到SQL Server中的公共管道，然後有一個單獨的進程處理管道中待處理的批處理。