我很想知道人們如何在他們的應用程序中管理他們的包。在不破壞代碼的情況下管理Oracle包的策略
例如，在我們的開發實例，應用程序開發人員可能需要更改的存儲過程。但是，更改存儲過程將會破壞現有的Java代碼，直到更新DAO層以適應更改。
我的典型做法是把新程序的實施爲「DEV」包。然後開發人員可以更改他對這個軟件包的引用，做他的測試，然後當我們準備好時，我們可以替換「生產」軟件包中的過程，將它從DEV中刪除，然後開發人員將他的引用更改回生產軟件包。
但是，我發現它不像我想的那樣順暢。首先，如果有一堆依賴於DEV包的Java代碼，那麼我就好像直接編輯生產包一樣 - 如果我打破了包，我會打破一堆代碼。
第二，人們忙碌起來，我們沒有得到周圍的包，我們應該儘快移動到生產中。然後，我們有兩個版本的存儲過程在四處漂浮，難以記住什麼已移到生產中，哪些沒有。
目標是保持開發人員的工作。是的，這是一個開發服務器，但我們不希望意外破壞代碼。
任何人都可以建議已經爲他們解決這個問題的方法嗎？
如果每個開發人員在數據庫中自己的模式和有在共享模式和所有的Java代碼使用非限定對象的名稱，在一個特定的開發架構中的包，然後一個本地副本中的所有對象的公共同義詞將優先於共享版本。因此，開發人員A可以使用當前版本的軟件包，將其安裝在他或她的本地模式中，對軟件包進行所需的任何更改，並在他們自己的開發環境中進行任何必要的Java更改（我假設開發人員有他們自己的本地應用服務器）。當這兩組變更足夠穩定以至於可以檢入共享開發環境時，PL/SQL包和Java變更都可以構建到共享開發環境（共享開發應用程序服務器和真實架構開發數據庫）。然後開發人員可以放棄他們的本地軟件包副本。
只要開發人員從源代碼管理中檢查PL/SQL以開始其更改，而不是假設他們的架構中的任何本地副本是最新的 - 如果開發人員保持舊的本地版本的代碼在他們的本地模式中，他們可能最終難以調試PL/SQL和Java版本不同步的問題。您可以通過自動化流程來解決該問題，例如，如果軟件包尚未在合理的時間內被修改，並且開發人員在源代碼管理中未檢出這些軟件包，或者通過構建腳本這讓開發人員可以將自己的模式刷新作爲構建過程的一部分進行自動化。
Java的/ DAO層應僅當程序規格變化的影響（的參數即號碼，姓名等）。緩解策略爲：
過程和函數使用軟件包，可以重載它們
創建或替換PKG是 PROC（在VARCHAR2 P1）; proc（p1 in varchar2，p2 in number）; 結束;
超載，你可以在一個包具有相同名稱的多個過程只是
11gR2的不斷推出Editioning來解決這個問題的參數不同數量和/或數據類型。它允許多個版本的軟件包，應用程序代碼選擇想要查看的代碼的「版本」（版本） - 默認的「基本」版本或開發版本。
但是我懷疑升級數據庫版本不是一個實際的解決方案。