[TEAP早期試讀]在資料庫中使用PL/SQL實現業務邏輯的優勢

圖靈社群按：
TEAP是什麼？TEAP是Turingbook Early Access Program的簡稱，即早期試讀，它公佈的是圖靈在途新書未經編輯的內容。一本書的翻譯週期約為3到6個月，如果在翻譯過程中，譯者就能與讀者進行溝通和交流，對整本書的翻譯品質是有幫助的。通過TEAP，讀者可以提前閱讀將來才能出版的內容，譯者也能收穫寶貴的反饋意見，改進翻譯，提高質量。

本書原名為Expert PLSQL Practices，中文暫定名為《Oracle PL/SQL實戰》，本篇選自第11章 大規模PL/SQL程式設計 第1節）

我的社群ID 、部落格

在資料庫中使用PL/SQL實現業務邏輯的優勢

大多數業務應用程式是以資料為中心的，因此它們的核心都需要資料庫支援。這些應用程式通 常會使用數年甚至數十年，在此期間，一方面，使用者介面有時會改變或擴充套件以跟上藝術的形 勢。另一方面，資料模型和業務邏輯通常會跟隨所要支援的業務流程更穩步地演進。許多這類 應用程式最後會發展得很龐大，無論它們始於小型（比如一個電子表格程式的APEX替代品） 抑或在發端時就很複雜。因此，我們需要一種架構和開發語言，這種架構和語言適合用數年時 間開發和維護以資料為中心的業務邏輯。Oracle資料庫的PL/SQL能完美地滿足這需求。

用PL/SQL編寫業務邏輯會導致大量的PL/SQL程式碼，例如，我們公司的旗艦應用程式擁有1100 多萬行程式碼，有170位開發人員在維護它，這是真正的大型程式設計。使用任何語言進行大型編 程，並保持靈活和高效需要良好的模組化和對程式設計規範嚴格遵守基礎上的高度統一。PL/SQL 提供了實現和強制執行這些方面的堅實基礎。另外，PL/SQL還支援物件導向程式設計，這能顯著 地增加複用，因而能在降低開發成本的同時提升軟體質量。

本章首先描述了為何及何時採用PL/SQL實現業務邏輯是一個不錯的選擇，然後解釋了掌握大 規模PL/SQL程式設計成功的關鍵因素的幾種方法。

在資料庫中使用PL/SQL實現業務邏輯的優勢：

·簡單：大多數開發人員在一個單一層只需要用一種語言編寫程式碼。他們能夠獨立編寫 完整的業務功能而不必花費時間去協調與等待其他層的開發人員做好本職工作。此外，並 發模型使得可以很容易地開發與其它模組並行執行的程式。 ·效能：資料訪問，包括批量操作，直接在資料庫處理是最快的。這與Exadata的基本思 路是相同的，即：使加工/處理更接近資料，並只把最少量的資料通過網路傳送。對於批量 處理這類OLTP銀行系統的主要功能，所有的處理都可以在資料庫進行。 ·安全：定義者權利的程式更容易確保未經授權的人不可以從資料庫外部訪問任何關鍵 資訊。所有資料都可以駐留在鎖定的模式中，並可以限制只有少數幾個包可以從外部訪問 這些資料。不需要授予直接訪問表或檢視的許可權。如果業務邏輯在資料庫外實現，那麼會 有（至少在一段時間後）多個應用程式直接訪問資料庫。這使得一致的安全策略很難強制 執行。在應用伺服器中儲存的密碼很容易被濫用在直接訪問資料上。此外，在資料庫？服 務器中的會話狀態還可防止欺騙攻擊。 ·一致性：我相信Oracle的讀一致性。如果我不得不在中間層快取同步負載很重的OLTP 活動的基礎上顯示實時的客戶明細表，那麼我不會睡得好。 ·任何環境下的可用性：許多應用程式需要與其它程式進行互動。任何語言都可以通過 JDBC，OCI，ODBC等呼叫儲存過程。當然，這也是真正的Web服務。 ·在分散式事務中的參與：分散式事務對需要確保執行一次且僅執行一次的業務系統的 介面是至關重要的。藉助Oracle的分散式事務，事務參與者設定是簡單的併為大多數事務 協調器所支援。另一方面，在一個多廠商環境中如果通過Web服務或CORBA中間層的資料 庫連線為任意介面建立/設定分散式事務，那簡直是一個噩夢。 ·集中化，單層的部署：即使表和業務邏輯需要進行修改，大多數的改進和錯誤修正也 只需要修改一個層。 ·可擴充套件性：憑藉功能更強大的伺服器和真正應用叢集（RAC），Oracle資料庫的規模 可很適當地內部擴充套件或水平擴充套件。 ·穩定性和可靠性：Oracle資料庫是一個非常穩定可靠的執行環境。

三層架構的大多數優點源於資料訪問、業務邏輯和展現的邏輯分離而不是物理分離。邏輯分離， 並因此帶來的好處，可以憑藉資料庫內的模組化實現，正如後面描述的那樣。 儲存過程可以用PL/SQL、Java、.NET或幾乎任何程式語言作為外部過程編碼。PL/SQL是我的首 選語言。

PL/SQL儲存過程

PL/SQL是一種專門設計的無縫處理SQL所必須的3GL，為業務邏輯編碼提供了額外的好處。

此外，基於版本的重新定義為PL/SQL程式碼與其他型別的物件提供了線上應用程式的升級。 PL/SQL還能在記憶體資料庫TimesTen中執行，從而帶來了與記憶體中快取資料相同的優點，以實現 更高的效能。

Java儲存過程

Java儲存過程不能提供與PL/SQL的相同的SQL無縫整合。事實上，Java沒有在圖11-2中列出的 任何優點。此外，對Oracle 11gR2而言，在Java儲存過程內呼叫SQL的效能比從PL/SQL呼叫或 在資料庫外執行的Java呼叫差很多。考慮到資料庫外的JDBC的表現是出色的，這很可能得到 改善。另一方面，在11g中，即時編譯器的演算法效能比PL/SQL更好，並且與資料庫以外的Java 幾乎相同。

如果PL/SQL無法完成某項工作，比如Oracle 10g之前的OS呼叫，或現有的Java庫能大大簡化工 作，那麼Avaloq使用Java處理這些工作。例如，Avaloq安裝工具使用Java檢查ZIP檔案的簽名， 並且在資料庫準備系統通過JDBC使用Java進行資料庫之間的LOB傳輸，而不是通過資料庫鏈 接使用PL/SQL，因為後者只在DDL中支援LOB，但不支援在DML中操作LOB。有許多庫可 用，絕對是一個Java生態系統的實力。然而，這一事實往往被高估了。對於業務應用程式，往 往只有基礎設施庫是有用的，而即使是那些可能也是不夠的。舉例來說，任何Java記錄框架都 不支援每個條目的安全性，把對相同的問題的記錄呼叫分組到一個單一的條目或關於條目的工 作流程中。此外，不斷出現的新庫，可導致強迫最新框架採用障礙，這通常體現在一個單一的 產品中用了許多類似的庫，因為對一個大型產品進行完全重構的努力是令人望而卻步的。最後 但並非最不重要的一點是，PL/SQL中也配備了大量的庫，在11gR2中，《PL/SQL包和型別參 考（PL/SQL Packages and Types Reference ）》已增加到5,900頁。

Java的一個好處是，可以在資料庫中或在另一層執行相同的程式碼，如資料驗證。後一種情況下 的另一種方法是由特定領域的語言生成PL/SQL和其他的語言程式碼。在Avaloq銀行系統中，一 半以上的PL/SQL程式碼是由更高層次的特定領域語言生成的。

雖然Oracle允許開發人員在子程式的基礎上，在PL/SQL和Java之間決定實現子程式（儲存過程 或函式）的語言，但是我儘量避免產生難以維護的二者的胡亂組合。

Java儲存過程，實際上是名不副實的。Oracle資料庫包括一個完整的Java虛擬機器（JVM）。因 此，它可能在任何幾十種包含生成Java位元組碼編譯器的語言中編寫儲存過程。從面向方面程式設計 的AspectJ到函數語言程式設計的Scala，但是，這些語言沒有任何一種支援（譯者注：原文sport，懷 疑是support）無縫的SQL嵌入。

SQLJ是以前處理器為基礎的Java擴充套件，它增加了簡單的SQL整合和自動繫結變數的語法糖衣。 然而，它缺乏嵌入式SQL編譯時檢查和引用的物件的修改後自動對依賴失效的跟蹤。自動驗證 失效需要JVM的增強，而無法通過語言擴充套件補充。 SQLJ支援是參差不齊的。支援SQLJ的整合開發環境很少有。在原有的10g版本中，Oracle本身 不再支援SQLJ。但在客戶投訴後，在10.1.0.4補丁集中SQLJ再次出現了。

基於.NET和C的外部程式

外部程式或子程式，因為它們在Oracle文件中是可互相替代的名稱，是一個遵守PL/SQL呼叫規 範並用另一種語言實現的子程式。通過編寫.NET儲存過程，你就把自己限制在Windows上運 行的Oracle資料庫上了。C語言編寫，或可以從C呼叫的另一種語言的外部程式，都會妨礙可移 植性。此外，外部程式都在自己的程式中執行。因此，基於C的外部程式除了可以通過資料庫 呼叫, 它們與中間層的業務邏輯相比沒有明顯的優勢。

用資料庫作為基於PL/SQL的應用程式伺服器的的限制

如果你是一把錘子，那麼一切看起來都像是釘子。另一方面，作為一個軟體工程師，你應該知道 架構藍圖的適用性限制。在資料庫中用PL/SQL描述業務邏輯的解決方案對資料為中心的ERP應用 是非常適合的，但它並不適合計算密集型的只需要很少的資料互動的應用程式。

此外，對於以下任務，PL/SQL不是我的第一選擇：

·CPU密集型任務：PL/SQL的演算法的效能比C和Java低。此外，應用PL/SQL有Oracle許 可成本。Java在商業應用伺服器發生類似的許可證費用，而執行C或獨立的Java程式無需運 行許可證。在Avaloq銀行系統中，PL/SQL程式佔了不足50％的CPU使用率，其餘的CPU是 用在SQL上。 ·程式在記憶體中使用非常大的集合：PL/SQL集合會需要比等價的C集合明顯更多的內 存。在本章後面會深入瞭解記憶體的使用。 ·非常複雜的資料結構：對大多數任務，使用PL/SQL集合與記錄就足夠了。然而，其餘 的任務可以更容易地用包含泛型型別，記憶體中的引用，並自動進行垃圾收集的語言來表 達。

■ 注意：有時人們用供應商的獨立性作為反對專有的儲存過程語言的原因。這種說法是無效的， 因為大多數應用程式永遠不會移植到另一個資料庫，而且因為取得良好的效能和正確的併發處理 在不同的資料庫需要多個具體實現，而沒有單一的通用實現。Tom Kyte在《深入Oracle資料庫體 繫結構（Expert Oracle Database Architectures）》（Apress，2005年）一書中詳細地描述了這一 點。我非常贊同他在該書這個主題中說的每一個字（雖然我不從Oracle公司領薪水）。這是兩回 事，你可以不喜歡某個特定的資料庫供應商，但是，你應該讓你選擇的資料庫發揮最佳效用。

軟因素

儘管Java可能比PL/SQL更有吸引力，但我發現僱用PL/SQL程式設計師比僱用同等的Java程式設計師不會 更難（可惜，也不更容易）。兩種語言的學習曲線並沒有太大的不同。PL/SQL是簡單易學的。 對程式設計師，特別是新畢業生的大挑戰是瞭解業務需求，學習大規模程式設計，掌握特定應用程式的框 架和模式，並編寫有效的SQL。 如果是用Java編寫的業務邏輯，那麼SQL也是一個問題。當然，瑣碎的SQL語句可以用物件關係 對映器生成。遵循一些簡單模式的SQL語句在PL/SQL中也不成問題，但是複雜的語句，為了達 到最佳效能必須手工地編碼。 在百萬行程式碼應用程式的公司中，使新員工容易入門，是大規模程式設計成功的主要條件之一。