但凡涉及(qing)多用户不同权限的|络或者单机程序，都会(x)有权限管理的问题Q比较突出的是MISpȝ?
下面我要说的是MISpȝ权限理的数据库设计?qing)实玎ͼ当然Q这些思\也可以推q开来应用，比如说在BBS中用来管理不同别的用户权限?
权限设计通常包括数据库设计、应用程序接?API)设计、程序实C个部分?
q三个部分相互依存，密不可分Q要实现完善的权限管理体p，必须考虑到每一个环节可行性与复杂E度甚至执行效率?
我们权限分c，首先是针Ҏ(gu)据存取的权限Q通常有录入、浏览、修攏V删除四U，其次是功能，它可以包括例如统计等所有非直接数据存取操作Q另外，我们q可能对一些关键数据表某些字段的存取进行限制。除此，我想不出q有另外U类的权限类别?
完善的权限设计应该具有充分的可扩展性，也就是说Q系l增加了(jin)新的其它功能不应该对整个权限理体系带来较大的变化，要达到这个目的，首先是数据库设计合理Q其ơ是应用E序接口规范?
我们先讨论数据库设计。通常我们使用关系数据库，q里不讨论基于Lotus产品的权限管理?
权限表及(qing)相关内容大体可以用六个表来描qͼ如下Q?
1 角色Q即用户l）(j)表：(x)包括三个字段QIDQ角色名Q对该角色的描述Q?
2 用户表：(x)包括三个或以上字D，IDQ用户名Q对该用L(fng)描述Q其它（如地址、电(sh)话等信息Q；
3 角色-用户对应表：(x)该表记录用户与角色之间的对应关系Q一个用户可以隶属于多个角色Q一个角色组也可拥有多个用户。包括三个字D，IDQ角色IDQ用户IDQ?
4 限制内容列表Q该表记录所有需要加以权限区分限制的数据表、功能和字段{内容及(qing)其描qͼ包括三个字段QIDQ名Uͼ描述Q?
5 权限列表Q该表记录所有要加以控制的权限，如录入、修攏V删除、执行等Q也包括三个字段QIDQ名Uͼ描述Q?
6 权限-角色-用户对应表：(x)一般情况下Q我们对角色/用户所拥有的权限做如下规定Q角色拥有明令允许的权限Q其它一律禁止，用户l承所属角色的全部权限Q在此范围内的权限除明o(h)止外全部允许，范围外权限除明o(h)允许外全部禁止。该表的设计是权限管理的重点Q设计的思\也很多，可以说各有千U，不能生搬套说某U方法好。对此，我的看法是就个h情况Q找自己觉得合适能解决问题的用?
先说W一U也是最Ҏ(gu)理解的方法，设计五个字段QIDQ限制内容IDQ权限IDQ角?用户cdQ布?yu)(dng)型字段Q用来描qC条记录记录的是角色权限还是用h限）(j)Q角?用户IDQ权限类型（布尔型字D，用来描述一条记录表C允许还是禁止）(j)
好了(jin)Q有q六个表Q根据表六，我们可以知道某个角?用户到底拥有/止某种权限?
或者说Q这么设计已l够了(jin)Q我们完全实C(jin)所需要的功能Q可以对角色和用户分别进行权限定Ӟ也具有相当的可扩展性，比如说增加了(jin)新功能，我们只需要添加一条或者几条记录就可以Q同时应用程序接口也无须改动Q具有相当的可行性。但是，在程序实现的q程中，我们发现Q用这U方法ƈ不是十分U学Q例如浏览某个用h拥有的权限时Q需要对数据库进行多ơ（甚至是递归Q查询，极不方便。于是我们需要想其它的办法。用过Unixpȝ的h们都知道QUnix文gpȝ对文g的操作权限分ZU：(x)诅R写和执行，分别???三个代码标识Q对用户同时hd权限的文件被记录?Q即1+2。我们也可以用类似的办法来解册个问题。初步的x(chng)是修Ҏ(gu)限列表，加入一个字D：(x)标识码，例如Q我们可以将录入权限标识?Q浏览权限标识ؓ(f)2Q修Ҏ(gu)限标识ؓ(f)4Q删除权限标识ؓ(f)8Q执行权限标识ؓ(f)16Q这P我们通过权限累加的办法就可以L的将原本要分为几条记录描q的权限攑֜一起了(jin)Q例如，假定某用户ID?Q库存表对应的限制内容ID?Q同时规定角色类型ؓ(f)0、用L(fng)型ؓ(f)1Q我们就可以该用户h录入、浏览、修攏V删除库存表的权限描qCؓ(f)Q?,15,1,1?
实很简单，不是吗？甚至q有更过Ȁ的办法，限制内容列表也加上一列，定义好标识码Q这P我们甚至可以用简单的一条记录描q某个用户具有的对全部内Ҏ(gu)h的全部权限了(jin)。当?dng)q样做的前提是限制内Ҏ(gu)量比较小Q不?dng)呵呵Q?的nơ方递增h可是数量惊hQ不Ҏ(gu)解析的?
从表面上看，上述Ҏ(gu)以辑ֈ实现功能、简化数据库设计?qing)实现的复杂度这个目的，但这样做有个弊端Q我们所涉及(qing)的权限列表不是相互独立而是互相依赖的，比如说修Ҏ(gu)限，其实是包含浏览权限的Q例如，我们可能只是单的讄用户对库存表存取的权限gؓ(f)录入+修改+删除Q?+4+8=13),但事实上Q该用户h(1+2+4+8=15Q的权限Q也是_(d)在这U方案中Q?3=15。于是当我们调用API询问某用h否具有浏览权限时Q就必须判断该用h否具有对该数据表的修Ҏ(gu)限，因此Q如果不能在E序中固化权限之间的包含关系Q就不能利用应用E序接口单的做出判断。但q与我们的目的“充分的可扩展性”矛盾?
q个问题如何解决Q我惛_?jin)另外一U设|标识码的方法，那就是利用素数。我们不妨将录入、浏览、修攏V删除、执行的基本标志码定?,3,5,7,11Q当遇到权限互相包含的时候，我们它的标识码讑֮Z个（或多个）(j)基本标志码的乘积Q例如，可以“修改”功能的标志码定?*5=15Q然后将所有的权限怹Q就得到?jin)我们需要的最l权限标识倹{这P我们在询问用h否具有某Ҏ(gu)限的时候，只需要将最l的值分解成质因子，例如Q我们可以定义一个用户具有录?修改+删除库存表的权限?2*15*7=2*3*5*7Q即表示Q该用户h?jin)对库存表录?览+修改+删除权限?
但凡涉及(qing)多用户不同权限的|络或者单机程序，都会(x)有权限管理的问题Q比较突出的是MISpȝ?
下面我要说的是MISpȝ权限理的数据库设计?qing)实玎ͼ当然Q这些思\也可以推q开来应用，比如说在BBS中用来管理不同别的用户权限?
权限设计通常包括数据库设计、应用程序接?API)设计、程序实C个部分?
q三个部分相互依存，密不可分Q要实现完善的权限管理体p，必须考虑到每一个环节可行性与复杂E度甚至执行效率?
我们权限分c，首先是针Ҏ(gu)据存取的权限Q通常有录入、浏览、修攏V删除四U，其次是功能，它可以包括例如统计等所有非直接数据存取操作Q另外，我们q可能对一些关键数据表某些字段的存取进行限制。除此，我想不出q有另外U类的权限类别?
完善的权限设计应该具有充分的可扩展性，也就是说Q系l增加了(jin)新的其它功能不应该对整个权限理体系带来较大的变化，要达到这个目的，首先是数据库设计合理Q其ơ是应用E序接口规范?
我们先讨论数据库设计。通常我们使用关系数据库，q里不讨论基于Lotus产品的权限管理?
权限表及(qing)相关内容大体可以用六个表来描qͼ如下Q?
1 角色Q即用户l）(j)表：(x)包括三个字段QIDQ角色名Q对该角色的描述Q?
2 用户表：(x)包括三个或以上字D，IDQ用户名Q对该用L(fng)描述Q其它（如地址、电(sh)话等信息Q；
3 角色-用户对应表：(x)该表记录用户与角色之间的对应关系Q一个用户可以隶属于多个角色Q一个角色组也可拥有多个用户。包括三个字D，IDQ角色IDQ用户IDQ?
4 限制内容列表Q该表记录所有需要加以权限区分限制的数据表、功能和字段{内容及(qing)其描qͼ包括三个字段QIDQ名Uͼ描述Q?
5 权限列表Q该表记录所有要加以控制的权限，如录入、修攏V删除、执行等Q也包括三个字段QIDQ名Uͼ描述Q?
6 权限-角色-用户对应表：(x)一般情况下Q我们对角色/用户所拥有的权限做如下规定Q角色拥有明令允许的权限Q其它一律禁止，用户l承所属角色的全部权限Q在此范围内的权限除明o(h)止外全部允许，范围外权限除明o(h)允许外全部禁止。该表的设计是权限管理的重点Q设计的思\也很多，可以说各有千U，不能生搬套说某U方法好。对此，我的看法是就个h情况Q找自己觉得合适能解决问题的用?
先说W一U也是最Ҏ(gu)理解的方法，设计五个字段QIDQ限制内容IDQ权限IDQ角?用户cdQ布?yu)(dng)型字段Q用来描qC条记录记录的是角色权限还是用h限）(j)Q角?用户IDQ权限类型（布尔型字D，用来描述一条记录表C允许还是禁止）(j)
好了(jin)Q有q六个表Q根据表六，我们可以知道某个角?用户到底拥有/止某种权限?
或者说Q这么设计已l够了(jin)Q我们完全实C(jin)所需要的功能Q可以对角色和用户分别进行权限定Ӟ也具有相当的可扩展性，比如说增加了(jin)新功能，我们只需要添加一条或者几条记录就可以Q同时应用程序接口也无须改动Q具有相当的可行性。但是，在程序实现的q程中，我们发现Q用这U方法ƈ不是十分U学Q例如浏览某个用h拥有的权限时Q需要对数据库进行多ơ（甚至是递归Q查询，极不方便。于是我们需要想其它的办法。用过Unixpȝ的h们都知道QUnix文gpȝ对文g的操作权限分ZU：(x)诅R写和执行，分别???三个代码标识Q对用户同时hd权限的文件被记录?Q即1+2。我们也可以用类似的办法来解册个问题。初步的x(chng)是修Ҏ(gu)限列表，加入一个字D：(x)标识码，例如Q我们可以将录入权限标识?Q浏览权限标识ؓ(f)2Q修Ҏ(gu)限标识ؓ(f)4Q删除权限标识ؓ(f)8Q执行权限标识ؓ(f)16Q这P我们通过权限累加的办法就可以L的将原本要分为几条记录描q的权限攑֜一起了(jin)Q例如，假定某用户ID?Q库存表对应的限制内容ID?Q同时规定角色类型ؓ(f)0、用L(fng)型ؓ(f)1Q我们就可以该用户h录入、浏览、修攏V删除库存表的权限描qCؓ(f)Q?,15,1,1?
实很简单，不是吗？甚至q有更过Ȁ的办法，限制内容列表也加上一列，定义好标识码Q这P我们甚至可以用简单的一条记录描q某个用户具有的对全部内Ҏ(gu)h的全部权限了(jin)。当?dng)q样做的前提是限制内Ҏ(gu)量比较小Q不?dng)呵呵Q?的nơ方递增h可是数量惊hQ不Ҏ(gu)解析的?
从表面上看，上述Ҏ(gu)以辑ֈ实现功能、简化数据库设计?qing)实现的复杂度这个目的，但这样做有个弊端Q我们所涉及(qing)的权限列表不是相互独立而是互相依赖的，比如说修Ҏ(gu)限，其实是包含浏览权限的Q例如，我们可能只是单的讄用户对库存表存取的权限gؓ(f)录入+修改+删除Q?+4+8=13),但事实上Q该用户h(1+2+4+8=15Q的权限Q也是_(d)在这U方案中Q?3=15。于是当我们调用API询问某用h否具有浏览权限时Q就必须判断该用h否具有对该数据表的修Ҏ(gu)限，因此Q如果不能在E序中固化权限之间的包含关系Q就不能利用应用E序接口单的做出判断。但q与我们的目的“充分的可扩展性”矛盾?
q个问题如何解决Q我惛_?jin)另外一U设|标识码的方法，那就是利用素数。我们不妨将录入、浏览、修攏V删除、执行的基本标志码定?,3,5,7,11Q当遇到权限互相包含的时候，我们它的标识码讑֮Z个（或多个）(j)基本标志码的乘积Q例如，可以“修改”功能的标志码定?*5=15Q然后将所有的权限怹Q就得到?jin)我们需要的最l权限标识倹{这P我们在询问用h否具有某Ҏ(gu)限的时候，只需要将最l的值分解成质因子，例如Q我们可以定义一个用户具有录?修改+删除库存表的权限?2*15*7=2*3*5*7Q即表示Q该用户h?jin)对库存表录?览+修改+删除权限?
]]>