數據交換設計建議

Question

基本上我們的情況是我們需要能夠從任意數據源（數據庫，平面文件，它可能是真的）獲取數據，對數據進行變形，以便映射到我們擁有的模式，然後將數據發送給我們，以便我們可以存儲它。數據將來自全國大約200個不同的物理位置，我們希望它按計劃運行（每晚一次或其他）。在200個地點的人也不是技術性的，所以我們想讓它儘可能簡單和無障礙。

尚未實現，它仍處於設計階段。這是我想出的一個初步設計，我只是想要SO的意見，以及他們可以預見的任何問題，或任何建議，以更好的方式做到這一點。

我想出了一個標準的獨立應用程序，它將接受不同的插件來讀取數據（從數據庫，平面文件等）。該插件將讀取數據並將所有內容提供給主標準應用程序，然後將其序列化爲XML並通過WSDL或某種REST API發送給我們（尚未決定，SOAP看起來像這樣的痛苦在屁股）。該應用程序可以通過Windows調度程序進行調度，也可以作爲cron作業運行，該部分很容易完成。

這樣用戶只需輸入數據的位置並可能如何到達（用戶名/密碼，主機等，無論需要什麼配置）。問題在於，我們不知道他們的數據會是什麼樣子，因爲沒有標準，每個位置都以他們自己的方式。我在想的是，顯然如果它是一個平面文件，那麼唯一的辦法就是發送整個文件。但是，如果它是一個數據庫，那麼如果某個配置文件不存在，它會向我們發送所有元數據（表，列名等），然後我們可以構建一個配置文件來告訴應用程序需要選擇哪些數據，e將其發送給用戶並告訴他們將配置文件放在某處。

我想這將是最簡單和最可能做我們這邊數據的實際變形，因此，如果它改變了我們沒有給他們任何東西，等等等等

這都將要用Java來完成，所以如果已經有一些模糊的Apache項目爲我做了這些，請讓我知道。

另外還有哪些其他存儲解決方案可以預見非技術人員使用標準SQL數據庫或平面文件？

Answer 1

您在這裏構建的是一個具有多個傳入和傳出數據配置文件的數據倉庫。

如果您研究任何EDI實施/白皮書，它可能會幫助您整體方法/思維方式。

這就是說，我已經成功地做了以下事情。

我在一個使用了太多不同數據輸入（Lotus Notes，Pervasive SQL，Excel/CSV，Foxpro和其他一些令我畏懼的環境）的環境中實現了它。我將所有數據導入標準的MySQL數據庫，然後我可以做任何事情。

在推行標準化格式時，您將不得不面對現實。我很想聽聽別人也做了什麼。

從較高的層面來看，您將會管理幾種類型的數據。

1）傳入/導入數據配置文件 - 這些將是您從一個列格式獲取的數據映射並轉移到您的標準化存儲格式。理想情況下，你可以設置一種你喜歡的方式。不可避免地，有人可能會做出不同的事情，或者您可能需要接受來自其他供應商/合作伙伴的數據，這些數據來自不同的結構，您需要將這些數據轉化爲您的數據。您可以爲每個位置構建傳入數據配置文件。

2）存儲的數據映射 - 這是所有數據以集中格式存儲的表格。所有數據都以這種格式存儲。

3）傳出/導出數據配置文件 - 每個人都需要不同結構和格式的數據。將查詢存儲在您運行的數據庫字段中，然後導出需要支持的導出格式（xml，csv，excel），這可能會最簡單。理想情況下，你想有一個「一般」的出口。不可避免地，你可能需要限制或自定義誰可以看到什麼..

功能：

• 如果你可以建立一個基於網絡的上傳這將是理想的。這可能會觸發上傳過程。如果您需要從客戶端網站自動執行更新，那麼運行某個東西並傳輸它的Windows調度程序也可能是可行的。

• 多個數據集：其中一個強大的功能是保留多個數據集的快照。當我們需要每天查看接收，發送，處理等內容時，上傳的內容等都會變得非常方便。

有了這些類型的數據，你可能想保存了幾個不同的數據集，所以你可能要考慮創建儘可能多的標準化這是可能的。在不瞭解人們使用的平板文件和數據庫的數量的情況下，您可能會拋出一個小程序或訪問數據庫，這些數據庫可能會壓縮excel文件並上傳。有很多不同的方法可以讓非技術用戶輕鬆使用。當然，聖盃 - 能夠自己進入並獲取數據，或者對每個位置的系統進行預編程，以便按照預定的格式發送他們想要的格式的數據，這樣他們就不需要觸摸它。

上面可能很簡單 - 但它可能是最好的。

Answer 2

如果可能的話，我認爲最好嘗試讓所有網站同意數量有限的格式和方法。也許你可以提供允許這種情況發生的工具。如果沒有，我認爲你會陷入維護噩夢 - 人們可能每天都在改變文件名，格式，位置，這取決於當天誰負責。你有我的同情心。

Answer 3

使用XML是相關的，因爲您正在處理與外部組織的互操作性，但它也是最重要的選擇。我建議考慮運輸的JSON，因爲它也被標準化和支持，但是更輕量。

至於整個項目，我必須同意其他人的看法，你應該得到我們的同情。即使與每個地點的技術人員進行協調，這也是一個困難的項目。如果沒有技術人員進行協調，我預計會出現失敗，或者至少是非常昂貴但最不令人滿意的成功。

一個關鍵問題將是每個位置數據的數量和複雜性。在不知道該項目是否跨越編程中小或大中之間的模糊閾值時很難提出建議。

但是，可以肯定地說，如果你不控制通信的雙方，這個項目將變得更加困難。我會追求在每個位置放置一個應用程序，與您所在位置的中央應用程序進行通信，以便您可以控制通信的雙方。

然後，我會努力在您的位置的那些遠程位置動態配置和擴展應用程序。理想情況下，將遠程應用程序設計爲簡單地作爲響應主站的從站 - 它們應該連續運行並檢查主站的配置，更新和命令以發送數據。一旦以最小的功能進行部署，您就可以專注於連接到數據源並從那裏探索您的選擇。同時，除非你的奴隸「消失」，否則你不必在遠方打擾別人。

當你控制雙方時，你可以選擇任何工具，技術和組件似乎適合，並隨意改變主意。

Answer 4

這不是像Informatica和Microsoft DTS這樣的ETL工具被髮明解決的問題嗎？還是我錯過了重要的事情？ 「