方案一多用戶多用戶方法
關於用戶權限的問題我認為這個問題在PB的開發中都可能遇到各人有各自的解決方法我以前也用過各種方法來實現但是總體而言安全性方便性靈活性等等方面考慮的話下面的的方案是一種比較好的方案
以下就該方案做詳細的說明
一基本知識
現在主要的DBMS包括ORACLE SQL ServerSybase Adaptive Server Microsoft SQL Server xx等在這些DBMS中都有自己完整的用戶管理模式一般都以下列方式進行
登錄用戶主要用來提供連接到數據庫服務的
角色用戶將登錄用戶劃分為某些組這些組擁有各種不同的數據庫操作權限而一個登錄用戶可以扮演不同的角色
組管理主要在Microsoft SQL Server x中在中已經采用ORACLESybase的用戶管理方式
DBMS提供了這些用戶管理的基本方式並各自對表視圖過程觸發器等有各自的審計及管理的方法關於這些內容請參考相關書籍
在實際的應用中如果實際情況允許可以對實際的所有用戶建立一個登錄用戶（帳號）並對所有的帳號進行嚴密的權限管理但是如果用戶的數量是不固定的而且可能有上百個那管理的復雜程度及難度就可想而知了
所以在一般的應用系統中很少直接采用DBMS提供的用戶管理模式而進行相關的擴充
二實現方法
當前比較可行的方法的要點是
所有的實體（表視圖等等）都由一個登錄用戶建立（dbo）但是該用戶不擁有連接及操作這些實體的權限（InsertDeleteUpdate等等）
對所有的實際用戶進行分類歸納為幾個具體的角色（實際角色）
一種實際角色對應一個登錄用戶建立帳號系統進行角色分配權限設置
在Application中某用戶連接時根據所扮演的實際角色以對應的登錄用戶登錄
根據對應表中對該用戶的可用模塊（功能）進行適當處理使用戶只在定制的]允許的范圍內進行功能操作及數據庫操作
根據以上幾點在一個具體的應用中涉及到的開發工作包括
表設計
實際角色（組）分析
建立應用用戶帳戶表該表記錄了該用戶所屬的組建立用戶組表
建立一個通用連接用戶（只能檢索用戶帳戶表）所有的應用用戶初始都以該用戶連接數據庫然後檢索根據實際登錄的用戶及用戶所屬組以該組對應的登錄用戶進行連接
建立模塊（功能）表建立用戶用戶組與該表的對應表即某用戶到底能夠進行什麼樣的操作
功能設計
建立模塊（功能）管理器管理所有可用模塊的相關信息
建立用戶用戶組權限管理器管理某用戶（組）能夠使用的功能
用戶啟動應用錄時將按照以下過程進行
○ 所有用戶都以固定的連接用戶進行初始連接
→ 用戶輸入自己的代碼及口令根據帳戶表確認該用戶
→ 得到該用戶所屬的組（即可以連接到數據庫的登錄用戶名稱）等信息
→ 重新連接到數據庫分配角色
→ 根據角色進行數據分片（參考數據分片技術）
→ 檢索該用戶所屬組及該用戶可用的模塊信息及布置調整菜單或界面
● 打開主窗口結束
方案二單用戶多用戶模式
所謂單用戶多用戶模式指數據庫的登錄用戶模式指所有應用都以統一的用戶登錄 該用戶擁有所有表視圖過程函數等的所有操作權限而這些對象都被dbo所創建和擁有可以將這些用戶稱為應用用戶（存放在某表中）而登錄到數據庫的這個用戶即為模式用戶 實際上為了防止系統外數據登錄可增加一個聯接用戶該用戶只能讀取一張表該表記錄了模式用戶的登錄參數（具體部分可以加密存放） 這種單多用戶方式在大型的mis系統中由於其實現簡單思路清晰所以應用是相當多的 單其優缺點是明顯的
優點
■設置簡單特別是授權可以比較輕松地實現
■管理簡單只要維護一個模式用戶就可以了
■對開發人員是透明的即開發用戶以dbo方式登錄就可以了
缺點
■比較危險一旦該模式用戶洩密將造成巨大損失
■無法進行進一步的權限設置因為不知道到底某應用用戶到底具有那些權限
改進（多用戶多用戶方式）
可以按照實際業務系統的分類劃分為幾個模式用戶如庫房給庫房一個模式用戶 財務則給財務另外一個模式用戶這些模式用戶對不同的對象擁有不同的權限從而防止了破壞不相關的業務系統數據的可能
在實際的使用中在登錄時可以根據該用戶所在的部門進行相關的聯接設置
方案三通過菜單來控制用戶權限 在PowerBuilder中是不支持動態菜單的一個菜單只能先做好然後在程序中調用或修改它的屬性因此對於動態菜單的實現只能通過打開一個個窗口實例來實現可以通過修改某菜單項的tag屬性在菜單項的clicked事件中打開該tag所指示的窗口即可
[] []
From:http://tw.wingwit.com/Article/program/PB/201311/24628.html
