但凡涉及多用戶不同權(quán)限的網(wǎng)絡(luò)或者單機(jī)程序，都會有權(quán)限管理的問題，比較突出的是MIS系統(tǒng)。
下面我要說的是MIS系統(tǒng)權(quán)限管理的數(shù)據(jù)庫設(shè)計(jì)及實(shí)現(xiàn)，當(dāng)然，這些思路也可以推廣開來應(yīng)用，比如說在BBS中用來管理不同級別的用戶權(quán)限。
權(quán)限設(shè)計(jì)通常包括數(shù)據(jù)庫設(shè)計(jì)、應(yīng)用程序接口(API)設(shè)計(jì)、程序?qū)崿F(xiàn)三個(gè)部分。
這三個(gè)部分相互依存，密不可分，要實(shí)現(xiàn)完善的權(quán)限管理體系，必須考慮到每一個(gè)環(huán)節(jié)可行性與復(fù)雜程度甚至執(zhí)行效率。
我們將權(quán)限分類，首先是針對數(shù)據(jù)存取的權(quán)限，通常有錄入、瀏覽、修改、刪除四種，其次是功能，它可以包括例如統(tǒng)計(jì)等所有非直接數(shù)據(jù)存取操作，另外，我們還可能對一些關(guān)鍵數(shù)據(jù)表某些字段的存取進(jìn)行限制。除此，我想不出還有另外種類的權(quán)限類別。
完善的權(quán)限設(shè)計(jì)應(yīng)該具有充分的可擴(kuò)展性，也就是說，系統(tǒng)增加了新的其它功能不應(yīng)該對整個(gè)權(quán)限管理體系帶來較大的變化，要達(dá)到這個(gè)目的，首先是數(shù)據(jù)庫設(shè)計(jì)合理，其次是應(yīng)用程序接口規(guī)范。
我們先討論數(shù)據(jù)庫設(shè)計(jì)。通常我們使用關(guān)系數(shù)據(jù)庫，這里不討論基于Lotus產(chǎn)品的權(quán)限管理。
權(quán)限表及相關(guān)內(nèi)容大體可以用六個(gè)表來描述，如下：
1 角色（即用戶組）表：包括三個(gè)字段，ID，角色名，對該角色的描述；
2 用戶表：包括三個(gè)或以上字段，ID，用戶名，對該用戶的描述，其它（如地址、電話等信息）；
3 角色-用戶對應(yīng)表：該表記錄用戶與角色之間的對應(yīng)關(guān)系，一個(gè)用戶可以隸屬于多個(gè)角色，一個(gè)角色組也可擁有多個(gè)用戶。包括三個(gè)字段，ID，角色I(xiàn)D，用戶ID；
4 限制內(nèi)容列表：該表記錄所有需要加以權(quán)限區(qū)分限制的數(shù)據(jù)表、功能和字段等內(nèi)容及其描述，包括三個(gè)字段，ID，名稱，描述；
5 權(quán)限列表：該表記錄所有要加以控制的權(quán)限，如錄入、修改、刪除、執(zhí)行等，也包括三個(gè)字段，ID，名稱，描述；
6 權(quán)限-角色-用戶對應(yīng)表：一般情況下，我們對角色/用戶所擁有的權(quán)限做如下規(guī)定，角色擁有明令允許的權(quán)限，其它一律禁止，用戶繼承所屬角色的全部權(quán)限，在此范圍內(nèi)的權(quán)限除明令禁止外全部允許，范圍外權(quán)限除明令允許外全部禁止。該表的設(shè)計(jì)是權(quán)限管理的重點(diǎn)，設(shè)計(jì)的思路也很多，可以說各有千秋，不能生搬硬套說某種方法好。對此，我的看法是就個(gè)人情況，找自己覺得合適能解決問題的用。
先說第一種也是最容易理解的方法，設(shè)計(jì)五個(gè)字段：ID，限制內(nèi)容ID，權(quán)限ID，角色/用戶類型（布爾型字段，用來描述一條記錄記錄的是角色權(quán)限還是用戶權(quán)限），角色/用戶ID，權(quán)限類型（布爾型字段，用來描述一條記錄表示允許還是禁止）
好了，有這六個(gè)表，根據(jù)表六，我們就可以知道某個(gè)角色/用戶到底擁有/禁止某種權(quán)限。
或者說，這么設(shè)計(jì)已經(jīng)足夠了，我們完全實(shí)現(xiàn)了所需要的功能：可以對角色和用戶分別進(jìn)行權(quán)限定制，也具有相當(dāng)?shù)目蓴U(kuò)展性，比如說增加了新功能，我們只需要添加一條或者幾條記錄就可以，同時(shí)應(yīng)用程序接口也無須改動(dòng)，具有相當(dāng)?shù)目尚行浴５牵诔绦驅(qū)崿F(xiàn)的過程中，我們發(fā)現(xiàn)，使用這種方法并不是十分科學(xué)，例如瀏覽某個(gè)用戶所擁有的權(quán)限時(shí)，需要對數(shù)據(jù)庫進(jìn)行多次（甚至是遞歸）查詢，極不方便。于是我們需要想其它的辦法。使用過Unix系統(tǒng)的人們都知道，Unix文件系統(tǒng)將對文件的操作權(quán)限分為三種：讀、寫和執(zhí)行，分別用1、2、4三個(gè)代碼標(biāo)識，對用戶同時(shí)具有讀寫權(quán)限的文件被記錄為3，即1+2。我們也可以用類似的辦法來解決這個(gè)問題。初步的想法是修改權(quán)限列表，加入一個(gè)字段：標(biāo)識碼，例如，我們可以將錄入權(quán)限標(biāo)識為1，瀏覽權(quán)限標(biāo)識為2，修改權(quán)限標(biāo)識為4，刪除權(quán)限標(biāo)識為8，執(zhí)行權(quán)限標(biāo)識為16，這樣，我們通過權(quán)限累加的辦法就可以輕易的將原本要分為幾條記錄描述的權(quán)限放在一起了，例如，假定某用戶ID為1，庫存表對應(yīng)的限制內(nèi)容ID為2，同時(shí)規(guī)定角色類型為0、用戶類型為1，我們就可以將該用戶具有錄入、瀏覽、修改、刪除庫存表的權(quán)限描述為：2,15,1,1。
確實(shí)很簡單，不是嗎？甚至還有更過激的辦法，將限制內(nèi)容列表也加上一列，定義好標(biāo)識碼，這樣，我們甚至可以用簡單的一條記錄描述某個(gè)用戶具有的對全部內(nèi)容所具有的全部權(quán)限了。當(dāng)然，這樣做的前提是限制內(nèi)容數(shù)量比較小，不然，呵呵，2的n次方遞增起來可是數(shù)量驚人，不容易解析的。
從表面上看，上述方法足以達(dá)到實(shí)現(xiàn)功能、簡化數(shù)據(jù)庫設(shè)計(jì)及實(shí)現(xiàn)的復(fù)雜度這個(gè)目的，但這樣做有個(gè)弊端，我們所涉及的權(quán)限列表不是相互獨(dú)立而是互相依賴的，比如說修改權(quán)限，其實(shí)是包含瀏覽權(quán)限的，例如，我們可能只是簡單的設(shè)置用戶對庫存表存取的權(quán)限值為錄入+修改+刪除（1+4+8=13),但事實(shí)上，該用戶具有(1+2+4+8=15）的權(quán)限，也就是說，在這種方案中，13=15。于是當(dāng)我們調(diào)用API詢問某用戶是否具有瀏覽權(quán)限時(shí)，就必須判斷該用戶是否具有對該數(shù)據(jù)表的修改權(quán)限，因此，如果不能在程序中固化權(quán)限之間的包含關(guān)系，就不能利用應(yīng)用程序接口簡單的做出判斷。但這與我們的目的“充分的可擴(kuò)展性”矛盾。
這個(gè)問題如何解決？我想到了另外一種設(shè)置標(biāo)識碼的方法，那就是利用素?cái)?shù)。我們不妨將錄入、瀏覽、修改、刪除、執(zhí)行的基本標(biāo)志碼定為2,3,5,7,11，當(dāng)遇到權(quán)限互相包含的時(shí)候，我們將它的標(biāo)識碼設(shè)定為兩個(gè)（或多個(gè)）基本標(biāo)志碼的乘積，例如，可以將“修改”功能的標(biāo)志碼定為3*5=15，然后將所有的權(quán)限相乘，就得到了我們需要的最終權(quán)限標(biāo)識值。這樣，我們在詢問用戶是否具有某項(xiàng)權(quán)限的時(shí)候，只需要將最終的值分解成質(zhì)因子，例如，我們可以定義一個(gè)用戶具有錄入+修改+刪除庫存表的權(quán)限為 2*15*7=2*3*5*7，即表示，該用戶具有了對庫存表錄入+瀏覽+修改+刪除權(quán)限。
但凡涉及多用戶不同權(quán)限的網(wǎng)絡(luò)或者單機(jī)程序，都會有權(quán)限管理的問題，比較突出的是MIS系統(tǒng)。
下面我要說的是MIS系統(tǒng)權(quán)限管理的數(shù)據(jù)庫設(shè)計(jì)及實(shí)現(xiàn)，當(dāng)然，這些思路也可以推廣開來應(yīng)用，比如說在BBS中用來管理不同級別的用戶權(quán)限。
權(quán)限設(shè)計(jì)通常包括數(shù)據(jù)庫設(shè)計(jì)、應(yīng)用程序接口(API)設(shè)計(jì)、程序?qū)崿F(xiàn)三個(gè)部分。
這三個(gè)部分相互依存，密不可分，要實(shí)現(xiàn)完善的權(quán)限管理體系，必須考慮到每一個(gè)環(huán)節(jié)可行性與復(fù)雜程度甚至執(zhí)行效率。
我們將權(quán)限分類，首先是針對數(shù)據(jù)存取的權(quán)限，通常有錄入、瀏覽、修改、刪除四種，其次是功能，它可以包括例如統(tǒng)計(jì)等所有非直接數(shù)據(jù)存取操作，另外，我們還可能對一些關(guān)鍵數(shù)據(jù)表某些字段的存取進(jìn)行限制。除此，我想不出還有另外種類的權(quán)限類別。
完善的權(quán)限設(shè)計(jì)應(yīng)該具有充分的可擴(kuò)展性，也就是說，系統(tǒng)增加了新的其它功能不應(yīng)該對整個(gè)權(quán)限管理體系帶來較大的變化，要達(dá)到這個(gè)目的，首先是數(shù)據(jù)庫設(shè)計(jì)合理，其次是應(yīng)用程序接口規(guī)范。
我們先討論數(shù)據(jù)庫設(shè)計(jì)。通常我們使用關(guān)系數(shù)據(jù)庫，這里不討論基于Lotus產(chǎn)品的權(quán)限管理。
權(quán)限表及相關(guān)內(nèi)容大體可以用六個(gè)表來描述，如下：
1 角色（即用戶組）表：包括三個(gè)字段，ID，角色名，對該角色的描述；
2 用戶表：包括三個(gè)或以上字段，ID，用戶名，對該用戶的描述，其它（如地址、電話等信息）；
3 角色-用戶對應(yīng)表：該表記錄用戶與角色之間的對應(yīng)關(guān)系，一個(gè)用戶可以隸屬于多個(gè)角色，一個(gè)角色組也可擁有多個(gè)用戶。包括三個(gè)字段，ID，角色I(xiàn)D，用戶ID；
4 限制內(nèi)容列表：該表記錄所有需要加以權(quán)限區(qū)分限制的數(shù)據(jù)表、功能和字段等內(nèi)容及其描述，包括三個(gè)字段，ID，名稱，描述；
5 權(quán)限列表：該表記錄所有要加以控制的權(quán)限，如錄入、修改、刪除、執(zhí)行等，也包括三個(gè)字段，ID，名稱，描述；
6 權(quán)限-角色-用戶對應(yīng)表：一般情況下，我們對角色/用戶所擁有的權(quán)限做如下規(guī)定，角色擁有明令允許的權(quán)限，其它一律禁止，用戶繼承所屬角色的全部權(quán)限，在此范圍內(nèi)的權(quán)限除明令禁止外全部允許，范圍外權(quán)限除明令允許外全部禁止。該表的設(shè)計(jì)是權(quán)限管理的重點(diǎn)，設(shè)計(jì)的思路也很多，可以說各有千秋，不能生搬硬套說某種方法好。對此，我的看法是就個(gè)人情況，找自己覺得合適能解決問題的用。
先說第一種也是最容易理解的方法，設(shè)計(jì)五個(gè)字段：ID，限制內(nèi)容ID，權(quán)限ID，角色/用戶類型（布爾型字段，用來描述一條記錄記錄的是角色權(quán)限還是用戶權(quán)限），角色/用戶ID，權(quán)限類型（布爾型字段，用來描述一條記錄表示允許還是禁止）
好了，有這六個(gè)表，根據(jù)表六，我們就可以知道某個(gè)角色/用戶到底擁有/禁止某種權(quán)限。
或者說，這么設(shè)計(jì)已經(jīng)足夠了，我們完全實(shí)現(xiàn)了所需要的功能：可以對角色和用戶分別進(jìn)行權(quán)限定制，也具有相當(dāng)?shù)目蓴U(kuò)展性，比如說增加了新功能，我們只需要添加一條或者幾條記錄就可以，同時(shí)應(yīng)用程序接口也無須改動(dòng)，具有相當(dāng)?shù)目尚行浴５牵诔绦驅(qū)崿F(xiàn)的過程中，我們發(fā)現(xiàn)，使用這種方法并不是十分科學(xué)，例如瀏覽某個(gè)用戶所擁有的權(quán)限時(shí)，需要對數(shù)據(jù)庫進(jìn)行多次（甚至是遞歸）查詢，極不方便。于是我們需要想其它的辦法。使用過Unix系統(tǒng)的人們都知道，Unix文件系統(tǒng)將對文件的操作權(quán)限分為三種：讀、寫和執(zhí)行，分別用1、2、4三個(gè)代碼標(biāo)識，對用戶同時(shí)具有讀寫權(quán)限的文件被記錄為3，即1+2。我們也可以用類似的辦法來解決這個(gè)問題。初步的想法是修改權(quán)限列表，加入一個(gè)字段：標(biāo)識碼，例如，我們可以將錄入權(quán)限標(biāo)識為1，瀏覽權(quán)限標(biāo)識為2，修改權(quán)限標(biāo)識為4，刪除權(quán)限標(biāo)識為8，執(zhí)行權(quán)限標(biāo)識為16，這樣，我們通過權(quán)限累加的辦法就可以輕易的將原本要分為幾條記錄描述的權(quán)限放在一起了，例如，假定某用戶ID為1，庫存表對應(yīng)的限制內(nèi)容ID為2，同時(shí)規(guī)定角色類型為0、用戶類型為1，我們就可以將該用戶具有錄入、瀏覽、修改、刪除庫存表的權(quán)限描述為：2,15,1,1。
確實(shí)很簡單，不是嗎？甚至還有更過激的辦法，將限制內(nèi)容列表也加上一列，定義好標(biāo)識碼，這樣，我們甚至可以用簡單的一條記錄描述某個(gè)用戶具有的對全部內(nèi)容所具有的全部權(quán)限了。當(dāng)然，這樣做的前提是限制內(nèi)容數(shù)量比較小，不然，呵呵，2的n次方遞增起來可是數(shù)量驚人，不容易解析的。
從表面上看，上述方法足以達(dá)到實(shí)現(xiàn)功能、簡化數(shù)據(jù)庫設(shè)計(jì)及實(shí)現(xiàn)的復(fù)雜度這個(gè)目的，但這樣做有個(gè)弊端，我們所涉及的權(quán)限列表不是相互獨(dú)立而是互相依賴的，比如說修改權(quán)限，其實(shí)是包含瀏覽權(quán)限的，例如，我們可能只是簡單的設(shè)置用戶對庫存表存取的權(quán)限值為錄入+修改+刪除（1+4+8=13),但事實(shí)上，該用戶具有(1+2+4+8=15）的權(quán)限，也就是說，在這種方案中，13=15。于是當(dāng)我們調(diào)用API詢問某用戶是否具有瀏覽權(quán)限時(shí)，就必須判斷該用戶是否具有對該數(shù)據(jù)表的修改權(quán)限，因此，如果不能在程序中固化權(quán)限之間的包含關(guān)系，就不能利用應(yīng)用程序接口簡單的做出判斷。但這與我們的目的“充分的可擴(kuò)展性”矛盾。
這個(gè)問題如何解決？我想到了另外一種設(shè)置標(biāo)識碼的方法，那就是利用素?cái)?shù)。我們不妨將錄入、瀏覽、修改、刪除、執(zhí)行的基本標(biāo)志碼定為2,3,5,7,11，當(dāng)遇到權(quán)限互相包含的時(shí)候，我們將它的標(biāo)識碼設(shè)定為兩個(gè)（或多個(gè)）基本標(biāo)志碼的乘積，例如，可以將“修改”功能的標(biāo)志碼定為3*5=15，然后將所有的權(quán)限相乘，就得到了我們需要的最終權(quán)限標(biāo)識值。這樣，我們在詢問用戶是否具有某項(xiàng)權(quán)限的時(shí)候，只需要將最終的值分解成質(zhì)因子，例如，我們可以定義一個(gè)用戶具有錄入+修改+刪除庫存表的權(quán)限為 2*15*7=2*3*5*7，即表示，該用戶具有了對庫存表錄入+瀏覽+修改+刪除權(quán)限。