1. Correct:符合使用者需求
這裡談到的是正確性，所謂正確性就是正確的達到使用者的需求，當然一大半是需求＆系統分析的事情，這裡Oracle管不著. 但是使用者的需求瞭解後，開發人員如何確定程式有做到該做的事呢？ 單元測試在當中扮演一個重要的角色，多數開發團隊會要求開發人員在程式開發完後提交單元測試報告，但是單元測試多由開發人員自行定劇本自行測試，涵蓋度和正確度如何無從得知？這時所謂的自動化測試（Automated regression test)就是一個重要的工具. 坊間常見的工具有 utPLSQL, PLUTO, PL/Unit, DBFit, Quest Code Tester. 這些工具的產品網址都在連接中，另外除了最後一個是要錢以外，其他看了都是Open Source的，大家有興趣可以試試！ 哪天也要自己的team試試，再將結果PO出來！
2. Fast Enough:效能好
- Optimizing Compiler
可參考以下文件有詳細說明. 在10G 後就有這項功能, 主要目的在提升PL/SQL在 runtime的效能. 而做法則是在 compile時, 使用不同的優化(Optimization)手段. 它是透過以下參數去控制,"PLSQL_OPTIMIZE_LEVEL". - Bulk processing
透過此工具, 將原始一筆一筆的處理方式轉換為多筆批次處理. 這篇文章對效能的提升有一些實驗和驗證(該文章號稱有三十倍快). - Pipelined table function
允許不同的 PL/SQL 間的資料傳遞不必受限於僅只傳遞參數而可以傳遞 ResultSet並且不用額外建立Table. 尤其在 ETL程式裡, 資料不必透過實體Table處理而是直接透過 Pipelined table傳遞, 對效能有一定的助益. 可以參考這篇文章. - Function result cache
可以參考這篇文章, 有完整的介紹. 簡短的說, function result cache的好處在, 當主程式呼叫另外的 PL/SQL function時, 這個 PL/SQL function可能含 SQL. 這會造成所謂的 Context Switch和 IO的增加. 因此 function result cache可以透過語法(Create function XXX (I1 varchar2) return varchar2 Result_Cache is) 設定將該 PL/SQL function的結果快取(Cached)起來, 加快處理速度. - Native compilation
參考"Optimizing Compiler"的文章, 所謂 Native Compilation就是將PL/SQL編譯成 C語言, 直接和Oracle整合, 效能較佳.
- Naming conventions & Syntax standards
變數和程式名稱的命名規則應該都要有文件作規範. - Writing SQL in PL/SQL
SQL的產生應該有一個獨立的Data Access Layer而不是任由開發人員在PL/SQL中 Hardcode. 透過這個Layer, 將SQL的複雜邏輯隱藏起來,以利後續的維護和開發. - Error Management
統一的 Error Handling 機制和模組. - Application Tracing
統一的tracing 機制和模組,可參考文章. - Version control and backups
版本備份, 我的團隊是用 Daily 從 Metadata中備份PL/SQL至檔案中, 以利未來查詢之用.
在你組成PL/SQL開發團隊前, 可以將上述的建議當成 Check List來確認開發團隊是否可以正確開發出快速且維護性高的系統.
