跨多數據源 J2EE 開發：DB2 Information Integrator vs 直接訪問深度對比

企業級應用常需整合來自 Oracle、DB2、Excel 等異構數據源的數據。本文詳細對比兩種架構：使用 IBM DB2 Information Integrator (II) 的聯邦技術 vs 手動編寫 Servlet 直接訪問各數據源並合併結果。結論顯著：II 方案減少 40% 代碼量、開發時間減半，且性能不遜色甚至更優。

一、 架構概覽

方案 A：DB2 Information Integrator 聯邦查詢

• Servlet 僅連接本地 II 服務器
• 查詢針對 Nickname（遠程表的別名）或基於 Nickname 的 UNION ALL 視圖
• II 全局優化器自動處理 SQL 方言差異、查詢分解、跨源連接優化
• 連接池管理簡單：只需一個 DataSource

方案 B：直接訪問 + 本地暫存表合併

• Servlet 需同時建立到 Oracle、DB2、Excel、本地 DB2 的四個連接
• Excel 需用 JDBC-ODBC Bridge，不支持 DataSource，只能用 DriverManager
• 每個查詢拆解為多條 SELECT（各源）、INSERT（寫暫存表）、最終 SELECT（查暫存表）、DELETE（清理）
• 開發者需手動處理 SQL 方言差異、分頁語法差異、跨源連接語義、聚合邏輯正確性

二、 環境配置對比

DB2 II 配置（一次性，通常由 DBA 完成）

-- 建立 Wrapper、Server、User Mapping、Nickname
CREATE WRAPPER net8;
CREATE SERVER jaqora TYPE oracle VERSION 8 WRAPPER net8
 AUTHORIZATION "demo" PASSWORD "cdidemo" OPTIONS (NODE 'iidemo2');
CREATE USER MAPPING FOR db2admin SERVER jaqora
 OPTIONS (REMOTE_AUTHID 'demo', REMOTE_PASSWORD 'cdidemo');
CREATE NICKNAME ora_part FOR jaqora.demo.part;

-- 調整數據類型映射
ALTER NICKNAME ora_part ALTER COLUMN p_partkey LOCAL TYPE integer;

-- 建立跨源 UNION ALL 視圖（含來源標識列）
CREATE VIEW fed_part AS
 SELECT db2_part.*, 'db2' AS p_server FROM db2_part
 UNION ALL
 SELECT ora_part.*, 'ora' AS p_server FROM ora_part
 UNION ALL
 SELECT odbc_part.*, 'xls' AS p_server FROM odbc_part;

直接訪問配置

• 需在本地 DB2 創建多張暫存表
• 配置 3 個 DataSource + 1 個 JDBC 1.0 連接
• 連接管理代碼膨脹，需區分連接類型處理

三、 查詢開發實戰對比

查詢 1：帶分頁的部件搜索

II 方案（單條 SQL）：

SELECT DISTINCT p_partkey, p_name, p_mfgr, p_type
FROM fed_part
WHERE p_type LIKE CAST(? AS VARCHAR(25))
  AND p_name LIKE CAST(? AS VARCHAR(55))
ORDER BY p_partkey
FETCH FIRST 20 ROWS ONLY

直接訪問（4 條 SQL + Java 邏輯）：

• DB2: FETCH FIRST 20 ROWS ONLY
• Oracle: 子查詢 + ROWNUM <= 20
• Excel: 無分頁支持，全量取回
• 本地: INSERT 暫存表 → 最終 SELECT + 分頁

查詢 3：時段內訂單金額 TOP 10 客戶（聚合陷阱）

直接訪問若各源各取 TOP 10 再合併，會遺漏跨源訂單合併後進入 TOP 10 的客戶。正確做法：各源全量聚合 → 本地暫存表 → 最終聚合排序取 TOP 10。II 方案單條 SQL 自動正確處理。

查詢 5：跨源平均訂單價值（聚合不可疊加）

直接訪問不能簡單平均各源平均值。需各源算 COUNT/SUM → 本地合併加總 → 算總平均。邏輯極其複雜，涉及 5 條 SELECT、1 INSERT、1 UPDATE、1 DELETE。II 方案單條 SQL 搞定。

四、 代碼量與開發時間統計

直接訪問開發時間約為 II 方案 2 倍；複雜查詢（如查詢 5）差距更大。

五、 性能表現

II 方案查詢響應時間與直接訪問持平，甚至有時更優。II 全局優化器基於統計信息自動選擇最優訪問路徑，而手寫邏輯難以適應數據分佈變化。

六、 總結

• 開發效率：II 顯著勝出，屏蔽了異構性、方言差異、查詢分解複雜度。
• 維護性：II 方案邏輯集中在 SQL，易讀易改；直接訪問邏輯分散在 Java+SQL 中，維護負擔重。
• 適用場景：需整合多異構源、查詢涉及跨源連接/聚合、團隊缺乏分佈式查詢優化經驗時，強烈推薦 II。
• 代價：需部署配置 II 環境（一次性工作），生產環境建議由 DBA 負責。

下一篇將詳細分析性能測試數據與調優細節。