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函數封裝，規范對全局變量的訪問。