我正在尋找最佳的解決方案,以允許我們的用戶上傳XLS電子表格,以便它們可以用來填充我們的數據倉庫(DW)中的表格。Excel上傳到數據庫表
我們的用戶是沉重的業務對象(BO)用戶,而BO可讓您導出到XLS。當電子表格中的數據需要加載到DW中時,他們需要一個過程將XLS中的數據上傳到DW的數據庫。因此,當我認爲我們真正需要的是一個程序化的自動化Feed時,我們會得到許多這些「界面」。使用Excel作爲跨系統提要的數據源,在我看來,對我來說,這似乎是一個壞主意。
問題1:我想看看你是否同意以及爲什麼或爲什麼。
好吧,沒有反對這種潮流的游泳,所以我現在將XLS上傳留給我們。現在我需要找到最佳解決方案。首先,我會解釋我們現在做什麼,然後我不喜歡它:
通過網頁,我們提供空的XLS文件(無行)與一組定義的列。每個文件旨在用於更新不同的目標dest表。在每個電子表格中都有一個「上傳」按鈕。推送上傳按鈕會導致電子表格中的宏將文件內容序列化爲CSV並將數據傳輸到服務器文件夾。定期調度程序觸發使用CSV文件作爲輸入的Informatica ETL作業,並將數據加載到自定義特定於XLS的登臺表中,然後在記錄將編輯傳遞到適當的目標表中時執行。遇到的任何錯誤都會記錄到錯誤表中。對於上傳的每個XLS文件,數據最終都會在一個單獨的特定於該文件的登臺和錯誤表中。
一些我不喜歡的事情包括我們的過程是:
1)在XLS過於暴露的宏代碼,例如包括密碼,可以被篡改和有保證的問題是用戶正在使用最新的XLS模板。 2)業務規則編輯被放置在ETL程序中,他們應該可能在那裏,但是因爲我們想要儘快地發現錯誤,即在電子表格中,編輯也被添加到宏代碼中。這會導致業務編輯的重複。我希望將這些規則集中在一個地方並集中控制。恕我直言,我認爲在XLS中放入任何宏代碼會引發維護問題,甚至會調用存儲過程(我們有一些存儲過程)或調用Web服務(我們還沒有嘗試從XLS宏調用.NET Web服務。 ) 3)每個XLS文件上傳模板都有自己的進程,其中包含不同的分段和錯誤表集以及用於報告遇到錯誤的自定義屏幕。看起來我們需要一個更廣泛的可重用解決方案。
除了經常從BO中獲取數據導出到XLS,用戶也喜歡Excel,因爲編輯大量記錄比通過Web界面編輯單個記錄更容易,而且更少笨重。
這是我想到的是大方向:
首先,我希望用戶擁有輕鬆與編輯的Excel的編輯,但不包括在電子表格中嵌入的宏。我嘗試用公司Farpoint的網格與Excel兼容...
http://www.fpoint.com/netproducts/spreadweb/tour/excel.aspx
...我發現,這是很容易讓用戶打開駐留在PC上,並有一個XLS文件的能力它在瀏覽器中打開並能夠輕鬆訪問從服務器端.NET Web代碼中讀取的數據。Excel沒有在瀏覽器本地運行,但是Excel的功能被複制,大概是通過很多客戶端腳本編寫的,我認爲這會讓我很難複製。您甚至可以從本地電子表格剪切並粘貼到網絡的電子表格中。這聽起來不錯,最大的問題是成本。我們的公司即將死亡,不會允許我們購買任何新軟件。
接下來,我想確定所有電子表格上傳處理中的通用組件,並提出通用處理代碼。例如,我想象一個表格,它定義了我們的每個電子表格以及每個表格的格式,包括列名稱和數據類型定義,可能是根據其目標列而不是硬編碼。基於這個表格模板定義,我可以從這個表格定義中生成可供下載的XLS模板。我還可以執行簡單的通用編輯,以確保輸入的數據與表格定義匹配。並且可以使用一個公共網頁顯示數據並允許報告數據類型不匹配錯誤,並允許用戶更正它們。我還將定義一個公用表,用於將數據存儲在「分段」表中,使用一個包含兩列,提交#,行號,名稱和值的表格。沒有更多的「定製一切」是目標。
接下來我需要決定在哪裏放置業務規則。我的部門管理層堅信,所有數據加載都應該通過Informatica ETL批處理流程完成,因此規則/編輯屬於「Informatica」。我沒有使用Informatica工具的經驗,我更像是一名.NET人員。因此,我不確定這些規則是如何實現的,但我懷疑它們不可重用,因爲它們可以被.NET網頁用來驗證特定記錄。您可以看到,在某些情況下,當用戶未執行批量上傳時,他們確實能夠編輯特定記錄,我希望ETL批量插入過程應用的相同編輯應用於單個更新通過網頁嘗試單個記錄。如果解決方案是編寫單個Web服務或存儲過程,可以通過網頁對單個記錄進行更新,或者對批量上載中的每條記錄調用數千次?後者聽起來效率低下。
你對上述任何事情的想法都會受到歡迎。
感謝您的評論 – ChadD 2009-06-12 02:10:34