資料庫的選擇不僅是技術決策，更是關乎企業競爭優勢的戰略抉擇。一旦確定方案，便必須充分發揮資料庫伺服器的潛能，將技術優勢轉化為商業價值。本文將深入探討 Java 2 Enterprise Edition（J2EE）環境、物件導向開發方法論，以及物件持久化與物件關聯式資料庫管理系統（ORDBMS）的關鍵議題。
J2EE 涵蓋數十項規範，理解其複雜性的關鍵在於回顧 Web 架構的演進歷程。早期 1996 年的 Web 環境以 Netscape 瀏覽器與伺服器為主導，HTTP 的無狀態請求-回應模型雖簡化了文件存取，但 CGI 協議在處理資料庫連接時效能低落，每次請求皆需建立、操作、關閉連接，大量時間消耗在連接管理上。
為解決此問題，業界提出兩種方案：讓 CGI 與常駐程序通訊，或擴充 Web 伺服器 API（如 NSAPI）使應用程式駐留於伺服器內，保持資料庫連接。這些嘗試為後來應用程式伺服器的誕生奠定基礎。
J2EE 作為 Java 規範，深受物件導向影響，目標在於提供可攜性、擴展性、交易控制等企業級特性的應用架構。其核心組件包括：
此架構支援透過 IIOP 協議直接與 EJB 通訊，突破瀏覽器介面限制。理解請求-回應模型、MVC 模式、EJB 類型與生命週期，是掌握 J2EE 的基石。
物件導向的封裝、繼承、組合特性（如 DICOM 醫療影像標準的階層結構所示）雖提升開發品質，但物件持久化卻形成「阻抗失配」難題。J2EE 提供 Bean 管理與容器管理兩種持久化模式，後者透過部署描述符與 EJB QL 簡化開發，但將資料庫降級為單純儲存裝置，可能犧牲效能。
DB2 UDB 與 Informix Dynamic Server 作為 IBM 旗艦級 ORDBMS，繼承關聯模型的集合處理優勢，並擴充物件特性：
以銀行貸款風險查詢為例：10 區域 × 100 分行 × 10,000 筆貸款，若採純物件方式需建立千萬級物件、傳遞億級訊息，造成記憶體與效能危機。利用 ORDBMS 內建聚合函數、預存程序在資料庫層完成風險計算，僅回傳結果集，可消除大量物件建立與網路往返。
J2EE 強調資料庫可攜性，但商業應用的核心目標是競爭優勢而非可攜性。過度追求最低共同標準會放棄資料庫獨特優勢。建議策略：隔離資料庫交互層，善用核心功能創造優勢，遷移時再處理差異部分。
J2EE 整合 50 年軟體進展，代價是高複雜度：多執行緒 EJB 共享、交易協調、效能調校、監控瓶頸等。專案初期必須組建含 DBA、SQL 專家、架構師的跨域團隊。以 DICOM 資料元素儲存為例，早期引入資料庫專家可將 24 張表關聯優化為單表加大物件欄位，大幅提升效能。
核心原則：
強大的 J2EE 應用必須發揮瀏覽器、應用伺服器、資料庫引擎三大組件的綜合優勢。透過將處理邏輯置於最適層級，可降低複雜度、大幅提升效能、減少硬體與程式碼成本，縮短上市時間。企業需建立將資料庫功能融入 OO 分析、設計、實作全階段的工具流程，並在專案啟動前納入資料庫專家，確保技術決策轉化為持久商業優勢。
