发个牢骚，折磨人的权限设计。

小弟最近写了一个MIS的小程序。
但其中客户的权限折磨了我许久。

因为开发周期比较短，所以没有把权限设计得很细，而是硬编码了几个角色，在每个窗体打开的时候检查是否有本窗体打开的权限，结果，客户的权限要求越来越细，最后到了这样的地方。

A用户仅能修改一个34个字段的表中的第1,5,9列。
B用户仅能个性A用户修改过的数据，其他的数据一概不处理，连查都不能查。B修改过后的数据，A就不能再修改了。
C用户仅能查看到其中的 1-13，15-17列
D用户能看到所有的数据，但什么都不能改。
E用户能看到A、B、F、G、H处理的数据，
F用户能看到A、B、H、J处理过的数据，并且可以修改他们的数据。
.......

MD，如果要做到这样，我岂不是要设计一个权限模块，细化到每个列的增删改？


[解决办法]
确实需要~
是麻烦点的
[解决办法]
写一个触发器或存储过程，如果表中存在用户列用触发器可以解决更新问题，查询数据只能使用存储过程了
[解决办法]
建议把能修改的字段做为一个表,不能修改的再做为一个表!
[解决办法]
建立一张角色权限表,再建立一个用户表角色表就行了
[解决办法]
这是你的表没有设计好, 3楼说得没错
[解决办法]
或者写个函数进行判断，，其实跟存储过程的效果一样
[解决办法]
E用户能看到A、B、F、G、H处理的数据，
F用户能看到A、B、H、J处理过的数据，并且可以修改他们的数据。
----------
除了这2条 其他的我们的系统都实现了 而且跑的不赖

其实就3块：
1。所有业务的权限控制 （这个最有用）

2。相应的数据查看过滤（比如业务员只能看自己的客户 就简单的加一个 where ...and 客户ID in (select xxx from yyy where empid='zzz')） 这个业务员很喜欢 不用每天看到一堆数据
3。具体莫一项数据（字段）的查看权限 这个米虾米用
[解决办法]
楼主走火入魔了！

其实很简单的设置几个标志位，再在SQL里面控制就可以了。

伪代码如下：

比如A用户的SQL：Select 1,5,9 from table for update;
B的SQL: Select 1,5,9 from table where update by A;
C的SQL: Select 1~13,15~17 from table for update;
D的SQL: select * from table for readonly
E的SQL: select * from table where update by A、B、F、G、H for readonly;
F的SQL: select * from table where update by A、B、H、J for update;
................

简单的思路，自己可以根据实际的情况，再概括一下，精简一下。

呵呵，最近再看C#，可以根据上面的思路，建立一个基类（或接口），其他所有的用户从这个基类继承，但都有update或者review 的方法，
用多态控制。
[解决办法]
问题解决了吗？
[解决办法]
兄弟
重构吧

[解决办法]
如果是菜单权限，可以用Tag,和一个权限表，＋一个人员表控制，
其它的如添加删除权限可以仪类似的方法去做

如果你自己做，最好有一套自己的，且完整的权限管理模块
[解决办法]
最简单的思路

不同的权限复制出不同的Form即功能相近的窗口

优点：不易出错 易于修改
缺点：工作量大
[解决办法]
数据库做的有问题,最简单的方法是多几个窗体用于控制不同的字段，实现权限分配．
[解决办法]
楼主，教你一个简单方法。
在那有34个字段的表里再加多一字段，存放跟权限有关的信息。
ABCDEF修改数据时，同时更新这字段的标志位。
而他们可操作的数据你就根据这字段的标志位来检索就是了。

这是一个比较快的方法，但不方便扩展。
[解决办法]
需要增加一个模块,该模块处理所有的权限事务

每个要求权限控制的表至少多建一个字段,放权限信息(新建的时候添该用户的基本信息)

新增加的模块有分配权限的功能,比如A能查B,c,d的权限,而f的确不能操作
建操作权限表,把操作这些信息的数据记录在一个表中

操作数据的时候,根据权限表中的数据操作(比如只能查,或者只能修改,只能修改哪些字段)

这些是麻烦,不过很实用
[解决办法]
还是把表细化吧!
分为几个表!
[解决办法]
做权限表吧。以后现细化。不然更麻烦
[解决办法]
客户是上帝啊！

[解决办法]
这样的需求出来,我在怀疑就算做出来了,在实际用的时候客户自己都不知道能不能搞得清楚做了些什么!
[解决办法]
既然表已经做好了,在表里面增加标记位是最好的方法了,然后再做个公用存储过程进行用户判断,以后修改也很方便