...以及如何授予這些權限。我在一個擁有70多個應用程序的大型IT部門工作，其中一些在SQL服務器上，大部分在Oracle中。每個系統都有一個產品，QA和Dev實例。我們（我是一名開發人員）只能訪問prod/qa，我很好。在SQL服務器開發實例中，開發人員給出了db_owner，它工作得很好。爭論在於我應該在DEV oracle數據庫中擁有什麼權限。開發人員應在開發人員數據庫實例中擁有什麼權限
我認識到最好的情況是讓每個開發者在他們的工作站上運行他們自己的實例進行開發，但是由於數據庫的大小，這並沒有被視爲一種選擇。
我也對如何應用這些權限感興趣。在oracle中，通過角色授予的權限在PL/SQL執行過程中不是活動的，因此角色（甚至是「dba」角色）沒有用處。這留下了使用內置帳戶（系統）或創建數十個用戶數十個數據庫，並直接授予每個數十個權限。 在我看來，讓開發人員登錄系統是很有意義的，但我們的DBA聲稱這是一個壞主意。
我們過去只給開發人員訪問應用程序帳戶。這適用於小型商店，但隨着開發商數量的增加，它會迅速失控。
下面就是我們現在要做的：
這具有確保任何前端應用的益處沒有被數據庫開發斷不斷進行重建一切。
DBA的其中一項工作是管理用戶權限。我不認爲系統是一個好主意，有幾個原因，而不是放棄整個架構的能力，我相信你不需要。話雖如此，但我認爲將所有內容都授予用戶並讓數據庫管理員管理這些權限是完全正確的，無論有多少個帳戶可能都有。無論如何，大多數DBA都會擁有可用於管理這些權限的腳本。
聽你的DBA，他們一般都知道他們在說什麼。
如果它只是一個開發實例;我希望所有用戶都將個人帳戶添加到管理員角色。這樣你仍然可以在每個用戶的基礎上記錄活動;但給開發者足夠的呼吸空間來做他們的事情。
我假設有相對較少的應用程序帳戶擁有實際的對象。因此，一個或多個邏輯應用程序由特定Oracle用戶擁有的表組成。這不會是SYSTEM或SYS，它不會是Oracle公司提供的任何帳戶。這將是您的DBA創建的帳戶。如果您熟悉Oracle示例模式，則HR用戶擁有HR模式中包含HR應用程序後端的所有表。
從「最簡單的事情可能有效」原則出發，我首先想到的是看開發人員是否可以直接登錄到這些應用程序帳戶。這不是最可靠的配置，而且您正在開放開發人員意外或故意造成一些可能難以跟蹤或輕鬆解決的損壞的可能性。但根據組織情況，它可以很好地工作。特權管理是微不足道的 - 應用程序所有者帳戶已經擁有它最需要的所有特權。
下一步將爲每個開發人員提供一個單獨的模式來開發，可能與數據庫中的公共同義詞加載以及應用程序代碼中缺少模式限定符一起，以便在開發人員的模式會自動覆蓋該對象的共享版本。這提供了更好的隔離。權限通常是通過創建包含開發人員需要的所有授權的腳本或通過創建腳本來將「已知好」帳戶的所有權限複製到新帳戶來授予的。這兩者都不是特別難寫 - 你只需確保所有的開發者都擁有相同的權限集合，這通常只是在授予新權限時運行的另一個腳本。
我的小組支持大約100個應用程序，其中約20個應用程序擁有自己的Oracle模式。我們已經走到了每個開發者都擁有模式密碼的道路上，並且很方便。但事後看來，我會建議每位開發人員使用自己的Oracle帳戶進行開發。主要原因是審計。
我認識到，最好的情況是將 讓每個開發他們的工作站進行開發， 上運行他們自己的實例 但由於 數據庫的大小，這還沒有考慮 的選項。
有沒有辦法解決這個問題，也許是通過減少個人副本中的數據量？這似乎是理想的解決方案，因爲它可以讓您進行任何需要的更改。然後，您可以在準備好時將它們提交給DBA，並讓他更新共享開發服務器。
如果您正在開發存儲的PL/SQL對象，那麼擁有這些對象的模式需要（如您所述）對所使用的對象進行顯式授予。如果您有一個'數據'模式，但是在您自己的個人模式中開發代碼，那麼您應該能夠將數據模式對象的訪問權授予您的開發模式。通常我會期望數據模式的用戶名/密碼。
關於系統特權（例如CREATE），我期望CREATE TABLE，TYPE，VIEW，PROCEDURE TRIGGER，SYNONYM。其他可能是適當的（例如，CONTEXT），取決於你做了什麼。 DBA可能會排除CREATE DIRECTORY，因爲如果使用不當，可能會造成損害。對於任何在他們中的特權（例如SELECT ANY TABLE，DELETE ANY TABLE）
對於性能調整/系統監控，在開發數據庫SELECT_CATALOG_ROLE是好的。如果DBA不喜歡風險，則可能需要就個人意見進行談判。閱讀您的版本的參考指南，並要求您提供任何您可能使用的資料。
+1包含源代碼管理+構建過程 - 對於誰來控制這個區域中缺點的結果有很多不同意見 – dpbradley 2009-09-20 12:04:56