Type 1：JDBC-ODBC Bridge
- 原理：JDBC → ODBC → DB
- 優：兼容無原生驅動的 DB（Access、舊系統）。
- 劣：雙層轉換、需客戶端裝 ODBC 驅動/管理器、故障排查極難、非純 Java、性能最差。
- 場景：遺留 Access/Excel 數據遷移、臨時方案。
Type 2：Native API（本地客戶端庫）
- 原理：JDBC → JNI → Vendor Client Lib (OCI, DB2 CLI...) → DB
- 優：性能優於 Type 1/3，廠商優化庫。
- 劣：需客戶端裝特定庫、非純 Java、跨平台差、遷移 DB 需重裝所有客戶端、廠商支持有限（如 SQL Server 無 Type 2）。
- 場景：極致性能要求、單一 DB 長期鎖定、客戶端可控環境。
Type 3：Net-Protocol（三層中間件）
- 原理：JDBC → 中間件 Server（通用協議）→ DB 專用協議
- 優：純 Java、客戶端零配置、遷移 DB 僅改中間件、支援防火牆/HTTP 隧道、集中連接池管理。
- 劣：多一跳網絡、中間件成單點、性能遜於 Type 4/2。
- 場景：異構 DB 環境、頻繁遷移、Applet/受限客戶端、企業級統一數據訪問層。
Type 4：Native-Protocol（純 Java 直連）
- 原理：JDBC → Vendor 純 Java 驅動 → DB Wire Protocol
- 優：零部署（隨應用打包）、跨平台完美、性能最強（直連）、無中間件單點、自動下載適配 WebStart/Applet。
- 劣：需 DB 廠商提供（MySQL 早期曾無，現已有），極少數嵌入式 DB 無線協議。
- 場景：95% 現代 Java 應用首選。
選型決策樹
DB 有 Type 4 驅動？ → 是 → 直接用 Type 4
↓ 否
需支援多種 DB/頻繁遷移？ → 是 → Type 3
↓ 否
只用 Access/舊 DB？ → Type 1
↓ 否
極致性能+可控客戶端？ → Type 2
↓ 否
拋出異常：無合適驅動
原則：**Type 4 為王，Type 3 為相，Type 2/1 為備胎**。架構師應在選型文檔中寫明理由，避免後期被動遷移。
