文章目錄
- 發布時間:2010.04.20 14:41 來源:賽迪網 作者:笑醉了
SQL Server許可權資料庫設計 發布時間:2010.04.20 14:41 來源:賽迪網 作者:笑醉了
當我們在用SQL Server資料庫開發系統的時候,經常會遇到系統需要許可權控制,然而根據許可權的控製程度不同有不同的設計方案。
1. 基於角色的許可權設計
這種方案是最常見也是比較簡單的方案,不過通常有這種設計已經夠了,所以微軟就設計出這種方案的通用做法,這種方案對於每一個操作不做控制,只是在程式中根據角色對是否具有操作的許可權進行控制;這裡我們就不做詳述
2. 基於操作的許可權設計
這種模式下每一個操作都在資料庫中有記錄,使用者是否擁有該操作的許可權也在資料庫中有記錄,結構如下:
但是如果直接使用上面的設計,會導致資料庫中的UserAction這張表資料量非常大,所以我們需要進一步設計提高效率,請看方案3
3. 基於角色和操作的許可權設計
如所示,我們在添加了Role,和RoleAction表,這樣子就可以減少UserAction中的記錄,並且使設計更靈活一點。 但是這種方案在使用者需求的考驗之下也可能顯得不夠靈活夠用,例如當使用者要求臨時給某位普通員工某操作許可權時,我們就需要新增加一種新的使用者角色,但是這種使用者角色是不必要的,因為它只是一種臨時的角色,如果添加一種角色還需要在收回此普通員工許可權時刪除此角色,我們需要設計一種更合適的結構來滿足使用者對使用權限設定的要求。
4. 2,3組合的許可權設計,其結構如下:
我們可以看到在中添加了UserAction表,使用此表來添加特殊使用者的許可權,改表中有一個欄位HasPermission可以決定使用者是否有某種操作的許可權,改表中記錄的許可權的優先順序要高於UserRole中記錄的使用者權限。這樣在應用程式中我們就需要通過UserRole和UserAction兩張表中的記錄判斷許可權。
到這兒呢並不算完,有可能使用者還會給出這樣的需求:對於某一種action所操作的對象某一些記錄會有許可權,而對於其他的記錄沒有許可權,比如說一個內容管理系統,對於某一些頻道某個使用者有修改的許可權,而對於另外一些頻道沒有修改的許可權,這時候我們需要設計更複雜的許可權機制。
5. 對於同一種實體(資源)使用者可以對一部分記錄有許可權,而對於另外一些記錄沒有許可權的許可權設計:
對於這樣的需求我們就需要對每一種不同的資源建立一張許可權表,在中對Content和Channel兩種資源分別建立了UserActionContent和UserActionChannel表用來定義使用者對某條記錄是否有許可權;這種設計是可以滿足使用者需求的但是不是很經濟,UserActionChannel和UserActionContent中的記錄會很多,而在實際的應用中並非需要記錄所有的記錄的許可權資訊,有時候可能只是一種規則,比如說對於根Channel什麼層級的人有許可權;這時候呢我們就可以定義些規則來判斷使用者權限,下面就是這種設計。
6. 涉及資源,許可權和規則的許可權設計