数据库设计的一个相对实用的权限验证设计方法

WEB应用开发当中，数据库基本上也会涉及到，而WEB系统的各种权限验证，正是数据库设计中非常必要，而且重要的概念。

一个WEB系统肯定是整合了各种各样的功能。那些功能那些用户可以使用？那些功能那些用户可以管理？这时就肯定涉及到权限验证的设计。在这里，我主要是想谈论一下，在以数据库为数据载体的数据层下，如何去设计相应的数据表来提供权限验证所必须的数据。

以一个小例子来说明问题：一个文章发布系统，主要功能：阅读、写文章、修改文章、删除文章。要求：授权了用户才能进行相应的操作。需求很清晰，重点就落在了数据库的设计上。为了不把问题复杂化，将本例的权限粒度设置为：用户属于某些角色，某些角色可以对文章进行某些操作。

对于对个小系统，首先会想到的是三个表：用户表(user)，角色表(role)，文章表(article)。而进行权限验证的设计可有两个方案。

方案一：由于某些角色可以对某些文章进行某些操作。所以，可以将不同的操作划分出一个权限表，里面存在着可以进行这个操作的角色及操作的文章id。可以增加如下的表：

读权限表(read)，

写新文章权限表(write)，

修改文章权限表(edit)，

删除文章权限表(delete) 。

可以想象到，例如读表中存在着以下字段：id，role_id，article_id ，说明了那些角色对那些文章有着读的权限。

这样设计出来的数据库，扩展性很好，但对于这样的一个方案，暴露的弱点也是很明显的！就是当，一个系统中有各种各样的功能时，如果对不同的功能都使用这样的实现方法，最终必定会构建出大量的数据权限表，造成数据库难以管理。

如何在扩展性和实际需要上找到一个平衡点，是数据库设计中的一个关键。在方案二中体现着这一点。

方案二：对于文章，无非就是增、删、改、读这三个功能，对这几个功能进行授权，可以直接将授权嵌入到文章表中。得到的表结构类似如下：article(id,topic,content,read,write,edit,delete)。功能授权嵌入到文章表后，问题又来了：如何给不同的角色授权？嗯，这也是一个技巧。方法可以这样：

例如角色id为2，3，4的可以对id为1的文章有read操作。则可以将2^2 + 2^3 + 2^4 = 28 这个数值填写到id为1这行的read字段中。ok，会有人问，这样做有什么用？当然有用，就是用于验证时用。

article(id,topic,content,read,write,edit,delete)。

数据行 1 28

当一个用户拥有2，4这两种角色时，要对id为1的文章进行阅读时。系统需要验证这个用户是否有权读，则可以首先取得id为1的article的read字段数值，即28。然后做以下判断：

for(用户的角色列表){

if(28 | 2^用户角色==28){ //28与2的3次方做或运算，因为等于28，说明有权，则跳出循环。

有权

break;

}else{

无权

}

}

这是一种很常用的小技巧，为什么做或运算后等于28就可以证明这个角色有权对这一篇文章阅读呢？你可以写出它的二进制码，并作一次运算，你就会明白其中的原理。

这样的方案，使数据表减小了四个，虽然这样的设计扩展性能不是特别的好。但是它却完全满足系统的需要，而且系统也不会进行大范围的扩展，如果说扩展是为了未来的功能作铺垫，那么，你要自问一句：未来在这个系统上扩展，还可行吗？未来的技术谁也不知道发展成怎么的一个样