海量資料轉換遷移的程式碼自動生成

系統軟硬體升級或者遷移中的資料遷移工作是一項涉及範圍很廣的工作，往往在源庫有數百上千個業務表需要根據一定的模型規則對映到新的資料庫中，模型的對映與業務密切相關。通常我們將業務劃分為多個域，域內表一級對映可以歸納為以下模型：
1， 一對一對映
2， 一對多對映
3， 多對一對映
4， 多對多對映
由於資料的完整性，安全性考慮，故每一條資料遷移的過程必須要有記錄其是否失敗的log，以便重傳，目前常見的方法是使用etl工具或者自己開發儲存過程來實現。ETL工具比如infomatica等，是將對映與程式碼生成還有資料執行以工具的形式整合了，使得工作人員關注於業務模型的分析，而不是程式碼的實現和優化，某種程度來說對於遷移過程的標準化，簡化有很大的優勢。不過缺點也很明顯：
1，這類東西都要錢，且是黑盒子；
2，這類東西本身就要花時間去學習使用方法，如複雜的對映和效能優化等
儲存過程的缺點也很明顯：
1， 開發人員的能力和程式碼千差萬別，後期維護困難，效能方面也不可控
2， 大量的效率低下的編碼工作使得專案成本升高
為了解決這些缺點，可以分析常見的對映模型，將程式碼框架化（一般按照域），並自動生成大量的型別定義，欄位排版等人工重複性低效率活動，實現程式碼結構的統一。這樣也容易在後期維護，優化。
程式碼生成主要根據具體的對映模型，框架程式碼大概的劃分如下：
儲存過程通用定義區（通用log或變數申明）
儲存過程與業務表相關的定義區（欄位或行型別變數申明，遊標等）
程式碼區（批量處理過程，欄位賦值，巢狀迴圈等）
Log區（應用log）
對於前面提到了4種對映模型，其實可以簡化為2種，多對多的源表必定是某種邏輯關聯的，相當於1對多，同樣的多對1簡化為1對1，具體在程式碼中實現就是將多表的關聯儘量放在遊標迴圈的外層，這裡一般涉及的都是全錶轉換或者絕大部分資料轉換，這種方法也是效能的一個保證。
這種方法生成的程式碼只是一個框架，業務對映需要程式人員填上，並且一些複雜的邏輯需要手動加上或者對現有程式碼稍作修改，不在話下。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16179598/viewspace-742348/，如需轉載，請註明出處，否則將追究法律責任。