大家好，今天给各位分享后台系统设计的一些知识，其中也会对信息管理系统设计进行解释，文章篇幅可能偏长，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在就马上开始吧！
后台系统资源/数据权限系统设计
鉴于后台的权限，数据分级越来越细化，越来越错综复杂，我对现有的项目后台进行了一个初步的升级。参照传统的CRM管理系统改造了权限系统。
在一套后台管理系统中，系统通常会有多种需求的用户登陆。例如系统维护人员、运营分析人员、文案编辑人员、部门管理人员等等，而系统维护人员登陆要看到日志界面和服务器监控界面，文案编辑人员要看到文章界面等等，不同的用户登陆到后台还需要展示不同的菜单和界面，
单单运营分析人员，在系统中可以可能有A分公司运营助理、B分公司运营主管、C部门运营经理、华东大区运营总监等等类型，A分公司的运营助理只能看A公司的运营数据，C部门运营经理只能看到C部门的运营数据，大区运营总监应该要看到属于华东大区的所有公司以及部门的数据，不同人员能够查看的数据范围应该是不同的
其次，上述提到的的文案编辑人员，还会区分出总编辑，和文案撰稿人，虽然同样能看到文章管理界面，但总编辑拥有添加、编辑、删除、审核、发布等功能，普通文案只有有添加、修改的权限。
本文将对上述提到的场景提出一种基础的解决方案。
【角色】：系统运维、运营分析、部门职员这类拥有不同权限功能的标签，我们称之为“角色”。
【组织部门】： A分公司、C部门、华东大区、无论大小我们统称为“组织部门”。
【岗位】：运营助理、运营主管、运营经理、运营总监我们统称为“岗位”。
【数据权限】：大区运营和部门运营所能看到的数据范围不同，我们称之为“数据权限”。
【资源权限】：文章管理撰稿人比总编辑少了审核、发布的功能，这些功能我们称之为“资源权限”。
有了角色，部门组织，岗位，数据权限，资源权限这5个概念的结合就可以结合出满足一般使用场景的权限设计。
我们将数据权限、资源权限接关联在一个角色上，然后将关联好的角色与用户绑定，这样就完成了权限对用户的分配。另外，我们也可以将角色关联在某个部门的岗位上，然后用户只要填写所属部门和岗位即可获得权限。
比如文案总编辑、撰稿人、审稿人、编辑助理这类有特定的功能职能的用户群体，我们能就可以创建成角色。但要注意的是，角色一般是可以多个同时并存的。比如创建一个新文案负责人，组织允许他既可以自己撰稿，也可以帮助别人审稿，这时候往往不会在当独为他设计一个撰稿审稿人角色，而是同时为他分配撰稿人+审稿人两个角色。这样，该用户的权限就变成了他所有角色关联的权限之和。从而减少因为权限的交叉带来的冗余角色。
岗位和角色的概念其实是挺相似的，一个岗位一定程度上代表了他在组织中的角色。然而同样的岗位在不同的组织部很可能是不同的： 例如A部门的采购主管和B部门的采购主管。同样是主管的岗位，但A采购公司规定可以查看整个部门数据、不允许查看订单，而B采购可以查看订单数据、但不允许查看部门其他采购主管的数据，从而造成了同岗不同权。
这时，我们可以单独为这些部门各自创建岗位，并将角色组直接关联在各自的岗位上。例如在A分公司中分配一个岗位叫做采购主管，然后我们为这个岗位预设好“采购数据分析员”，“采购数据录入员”，“订单审核人员”的角色。这样以来，当A公司来了一位新的采购主管，我们只要为他创建好账号，然后为他设置这个岗位就可以实现权限的绑定。
撰稿人可以编写文章，审稿人只能查看和标记审核结果，区分两者权限不同，依靠的就是资源权限的不同。我们可以在撰稿人角色上绑定“文章:编辑、文章:查看、文章:添加”这三个资源权限，为审稿人角色绑定“文章:查看、文章:审核”两个资源权限，然后在系统中判断用户的权限来控制相应的入口显示。例如判断用户的权限中不包括“文章:审核”权限，页面就隐藏掉审核的开关按钮。
数据权限我们目前只分三种，“仅自己数据”，“部门数据”，“全部数据”。如字面含义一样，“仅自己数据”只能查看与自己直接关联的数据，比如自己的销售额，自己的考勤记录。“部门数据”允许用户看到整个部门乃至下级部门的所有成员的数据，比如整个部门的销售额，部门中某个用户的考勤记录。“全部数据”属于最高级别的数据权限，一般是平台的总公司总经理、或者某个系统的总负责人可以使用的到。需要注意的是，数据权限需要结合“资源权限“以及下面将提到的“组织部门“一起组合使用才能发挥效果。
组织部门可以区分用户在系统中的不同组织、不同等级关系。比如一个平台往往可以接入众多的公司，如图
组织与组织之间有明显的层级架构关系，结合数据权限、资源权限、角色、岗位、就可以灵活配置出例如图中销售部门A的销售经理权限，以及销售团队1的队长权限等等。
上述的结构只是一种方案，当然方案不可能是万能的，具体的实现还需要结合实际项目需求进行设计开发。
网站后台管理系统该有些什么亮点
亮点可以是技术上的,
如软件结构设计,数据库设计,可以更灵活的处理业务变更,更短期的完成编码,更少的BUG和更强的容错机制.
也可以是面向用户体验的,用户如何使用的更方便,环节视觉疲劳,减少鼠标点击和键盘操作次数.更美观的界面,进度条及操作状态提示,
还可以是面向硬件效能提升的,更流畅的运行速度,更少的加载时间,更小的数据存储容量,更小的内存消耗,更小的服务器载荷等等
但是归根结底,任何一项新技术的采用都是为了降低成本,提高利润.达不到这个目的,莫不如不采用
---------------------
不要把眼光局限在添加修改删除上,当然,你能意识到这一点,说明你已经具备的向更高目标迈进的可能性,脱离初学者阶段了.
后台ui设计注意什么
设计师在进行UI设计时，总有自己的想法与设计方案，但是，无论是多么创意的设计，在基本的几个方面，还是要遵照以下的几点：
软件的智能和记忆功能
1.用户登录界面最好有用户名和ID的记忆，焦点直接定位到密码输入框
2.单据录入界面最好有保存和载入默认值的功能
3.单据搜索界面可以保存用户自定义的各种搜索条件组合
4.用户调整过的GRID的列宽，窗口的位置可以自动记忆
5.系统可以根据用户的使用频度对相关功能进行自动的优先级排序
6.系统能够记忆不同用户的使用偏好，使用系统的固有模式和常用的自定义设置
减少不必要的重复交互
1.减少不必要的各种操作，能够点一次鼠标或敲一次键盘完成的绝不作出两次或多次
2.提示信息要适度，太多不好，太少也不好
3.数据项完整性校验问题要注意光标焦点自动定位到错误处
4.完整业务功能不要让用户在多个窗口切换多次才能够完成。尽量减少这种切换
5.为了方便用户切换窗口，相关的表单最好都作为非模式的形式
6.相同的信息不要让用户在系统中多处或多次录入，保证入口的唯一性
7.系统要尽可能根据用户已经录入信息自动获取其它附属信息，而不需要用户重复的选择或录入
导航和界面跳转
1.表单新弹出对话框，对话框再弹出对话框的这种层次要控制在3层以内。
2.所有的非模式活动窗口最好有类似桌面任务栏一样的停靠方式，方便切换窗口
3.系统可以支持用户自己定义常用功能和菜单
4.对于常用功能应该提供便捷的快捷键和工具栏按钮
5.对于系统中提供的各种业务和表单功能能够让用户便捷挑转到帮助信息上
6.对表单和界面联动和交互的时候要注意相关界面数据的自动刷新
7.一个窗口中最多不要出现超过三个的GRID控件
8.BS方式不要左右滚屏。CS模式既要避免左右滚屏也要避免上下滚屏
9.需要根据业务查看需求和数据的展现需求来选择合适的界面控件
系统性能和健壮性方面的
1.系统中相关的耗时操作都必须必须转变鼠标为等待状态
2.系统耗时操作超过30秒的最好能够提供给用户相关的进度条功能
3.系统耗时功能超过2分钟的最好能够设计为异步多线程的方式进行处理
4.系统应用有友好的完整性和约束校验的提示信息，方便用户修改录入数据
5.在系统出现异常情况下应该有友好的统一的提示信息，同时后台应该记录详细的异常日志
好了，关于后台系统设计和信息管理系统设计的问题到这里结束啦，希望可以解决您的问题哈！