PL/SQL最差實踐

1.超長的PL/SQL代碼

影響：可維護性，效能

癥狀：

在複雜的公司專屬應用程式中，存在動輒成百上千行的預存程序或上萬行的包。

為什麼是最差：

太長的PL/SQL代碼不利於閱讀，第三方工具在調試時也會出現程式碼混亂等問題。PL/SQL儲存物件（預存程序、包、函數、觸發器等）行數上限約為6000000行，但實際工作中，當包大小超過5000行就會出現調試問題。

解決之道：

PL/SQL代碼在執行前會被載入到shared pool中，shared pool以位元組為單位，UNIX下為64K，案頭環境下為32K，可以通過查詢資料字典USER_OBJECT_SIZE的PARSED_SIZE欄位查看對象大小。對於較大的包，應採用拆包策略，抽取複用部分，減少重複代碼；對於較大的預存程序，應將預存程序組織到包中，易於管理；對於較大的匿名塊，應將匿名塊重新定義成子過程儲存在資料庫中。

2.脫離控制的全域變數

影響：可維護性

癥狀：在包中使用了全域變數，在多個位置對全域變數進行操作。

create OR REPLACE PACKAGE BODY PKG_TEST IS
GN_全域變數 NUMBER(12, 2);
PROCEDURE 過程A IS
BEGIN
GN_全域變數:=1;
END;
PROCEDURE 過程B IS
BEGIN
GN_全域變數:=2; -- 這裡對全域變數進行了另外的操作
END;

為什麼是最差：

全域變數可以在整個包範圍內被訪問到，因此對全域變數的跟蹤和調試會比較困難。如果變數是在package中定義的，變數還可以被其他包訪問，這將會更為危險。

解決之道：

減少或取締全域變數的使用，對於要在過程間互動的變數，通過參數傳遞來實現。如果必須使用全域變數，應對全域變數進行get/set函數封裝，規範對全域變數的訪問。