软件设计后台操作用户权限管理的方案

B/S系统的授权确实比C/S系统的授权重要得多。
由于客户端比较特殊，所以C/S权限很容易实现，可以在客户端完成，也可以在客户端+服务器完成。
还有B/S？每个人都有一个浏览器。
如果没有权限检测的话，只要找一个浏览器访问一下，系统就会彻底被扰乱。
因此，B/S系统必须实行授权控制，那些被授权使用功能的人，如果没有授权，就会被彻底封杀。

需求中提到，不同的人有不同的权限，必须实现组的概念。
公司员工很多，一一添加权限太慢。
将具有相同权限的人分成一组并将他们全部添加到一个组中要容易得多。
系统必须是可扩展的，就像基本元素一样。
任何系统都可以添加，所以不要每次都这样做。

数据库设计至关重要。
操作表、组管理器表和主表是记录权限、组和人员信息的三个主要表。
它们之间是多对多的关系。
一个权限属于多个组，一个组有多个权限；一个人属于多个群体，一个群体有多个成员。
这个关系太复杂了，所以用两个映射表来解决：actiongroup表和mastergroup表。
第一个连接权限和组，第二个连接员工和组。

还有一个权限列表来控制浏览器左侧的菜单列。
例如“用户管理”属于“系统管理”栏目，“订单查询”属于“业务操作”栏目，这样菜单就一目了然。

这三个主要表格侧重于基本要素：权限、组和人员。
两个映射表建立了关系。
难点在于映射表，它记录了关系并实现了分组功能。
整个设计是为了可重用而设计的，可以在任何业务系统中使用。
如果数据发生变化，结构不需要改变。

附录中六个表的具体字段：actions表存储动作和描述； action列表存储列信息；动作组表存储动作分组； groupmanager表存储组信息； mastergroup表存储人员分组关系；主表存储员工信息。

数据库设计,根据下面的叙述:应该设计哪些表?都有什么字段?

你好，我有点理解你的设计思想，但有点令人困惑。
我们来一一了解一下。

我们先来说一下指标表。
你是对的。
每个表仅列出主要功能，您可以自行添加其他要求。
这不是问题。
我设计的三个表，指标表、模型表、模型指标对应表，看起来是解决了多对多的问题。
但你说“表单指针对应的表：指针id，表单id（复合主键）”，让我一头雾水。
复合主键一般用来表示一个独立的实体或者两个表之间的直接关系，但是你对应的表描述的更像是关联关系。
如果表单和指针是多对多的，则使用指针ID和表单ID作为对应表中的外键，然后添加唯一约束（或称为组合唯一索引）。
这意味着每对模式和指标只有一个相关性，对吧？直接使用复合主键是不合适的。

我们来谈谈学生和课程。
多对多没问题。
我设计的用户表（加上权限字段）、课程表和课程选择表如下所示。
在课程选择表中使用用户ID和课程ID作为复合主键是可以的。
但你说，“讲师和课程之间必须是一对一的关系。
将讲师的用户ID作为外键添加到课程表中”。
我要和你争论。
在一对一关系中，通常有两种设计：要么表A有一个到表B的外键，要么表B有一个到表A的外键。
你可以将教师（用户）外键添加到课程表中，这看起来很合理，因为一门课程通常由一位教师负责。
但反过来说，将教师ID放入教学大纲中也很常见。
但是，想一想，一个老师可以教多门课程吗？如果可以教多个，就意味着多对多，外键不应该直接添加到课程表中。
如果完全是个人的，选课表就没有必要了吗？换句话说，为什么选课表很重要？学生选择课程，与老师的关系是间接的。
如果你还是觉得课程和老师各自为政，那么你会考虑删除选课表吗？或者选课表还是需要的，但是表的结构需要改变，比如学生ID、课程ID、选课时间等。
这里我很困惑，你的设计意图应该更清晰一些。

最后我们来谈谈样本管理。
你所说的“看起来应该是对应一一对应的模型，表模型：样本id（主），样本id（外部）”，这个理解是正确的。
模型训练需要一组对应的样本数据，通常是一一对应的。
设计简单、清晰、完美。

在评估模型的第三部分，我设计了两种类型。
（主）评价表ID、（外部）用户ID等看上去是评价行为主体（如学生）对特定对象（可能是一门课程、表格等）的评价。
评估表ID和表单ID（复合主键）意味着评估与特定表单直接相关。
这两种评价模型是否同时存在？评价的主体是学生还是教师？评估对象主要是模型还是课程？这里的描述有点模糊。
如果评估的主体主要是学生，那么第一种评估表可能更合适，以评估ID为主键，学生ID和评估对象的ID（课程ID或表格ID，一个或两个字段即可）。
如果评估主体主要是教师，您可能需要添加另一个字段来区分评估者的角色。
表单 ID 和评估 ID 用作复合主键。
每个模型似乎只有一个评估记录。
这看起来很不合理，不是吗？可以肯定的是，一个模型可以有多个评估。

无论如何，你可以看出，我仍然很困惑。
尤其是教师与课程、学生与课程的关系以及考核模型的设计，需要我们更加清晰地思考。

谁能说说权限是如何设计的?

上周，一位客户问我为什么设计真理没有完美的解决方案，所以我告诉了他这一点。

你看，像Windows这样的操作系统都有针对角色级别设计的权限，这其实是很合适的。
如果权限可以控制到一个文件、文件夹，甚至是文件的某一行，那就相当麻烦了，好像设计过度了。
然而，在软件开发中，添加授权控制功能是非常关键的，尤其是在数据库开发中。

通常我们通过菜单访问功能来实现授权控制，即不同的用户可以访问不同的功能菜单。
但问题就在这里。
为了提高现有软件的可操作性，同一个功能可能有多种访问方式，如工具栏、右键菜单等。
同一个功能也可以在软件的不同地方调用，而不仅仅是主菜单。
这样的设计是为了保证软件的易用性。

现在常用的设计方法是基于角色，即用户权限。
首先判断用户所属的角色，然后检查角色的权限，最后利用权限判断用户是否可以执行操作。
然而，这种方法也有局限性。

之前看过一篇博客，里面提到了一些数据库设计的思想。
您可以查看：http://www.cnblogs.com/wuhuacong/archive/2 009 /06 /1 9 /1 5 07 06 5 无论如何，这取决于我，我还在考虑这个问题。