汽车租赁系统

在这里插入图片描述

在这里插入图片描述

学生课程管理系统

需求: 学校每个班级的学生,每学期至少完成4门主修课和1~2门的选修课。设计表结构,存储学生的课程学习信息和成绩信息。

多对多的表设计
多个学生对应多个课程,就需要一个额外的《对应关系表》,来记录每个学生选择的多个课程。简称:中间表,只为存储对应关系

在这里插入图片描述

学校设备管理系统

在这里插入图片描述

租房系统

在这里插入图片描述

外卖系统

在这里插入图片描述

会议室管理

在这里插入图片描述

物流系统

在这里插入图片描述

学校考试系统

在这里插入图片描述

用户管理

与 题目相关的表 关系不是那么密切,可以独立出来
在这里插入图片描述

题库中新增试题

字段包括:课程分类,知识点分类,题型分类,答案

  • 课程表
  • 知识点表 (每个知识点对应一个课程,关联关系)
  • 题型表(分为主观题+客观题,客观题分为:单选题、多选题、填空题、简答题)
  • 题库表(保存题目具体题干,包括:提干内容、答案、答案解析、图片url、题目状态【可用+不可用】)
  • 选项表(针对选择题专门单独出来的表,一个题干有对应多个选项,顺序使用序号字段保存,1234对应ABCD)
  • 题目 知识点 关系表 (一个知识点有多个对应题目,一个题目可以对应多个题目,多对多)
    在这里插入图片描述

生成试卷,选择题目

  • 试卷信息表:要指定所属班级,出题人,
  • 试卷题目信息表:根据题型+知识点从题库中过滤题目,然后选择需要的题目。
    这样每个题都会关联该套试卷,每道题还要设置题号,依照题号排序显示。
    在这里插入图片描述

组织考试

设置考试名称(选择哪一门课程)
选择考试时间、日期,然后才能发出通知
选择具体使用哪一套试卷,包括历史试卷
选择参加考试班级
选择阅卷老师

  • 组织考试表
  • 阅卷权限表
    在这里插入图片描述

开始考试

  • 考生答卷信息表:表示哪位学生考了哪次考试,包括答卷id,试卷id,老师id,学生id,总得分
  • 考生答案组成表:详细记录该考生所有答案,试题id+答案内容,阅卷老师输入主观题得分

教师阅卷

  • 教师阅卷权限表:有权限就可以查看得分具体情况,也可以二次修改阅卷情况。

系统权限设计思路

简单系统

简单,指的是系统中用户需要区分的权限很少,且用户进入系统后不需要进行具体模块的权限区分,
只有普通用户、管理员两种,那么将普通用户单独建表,管理员单独建表,登录时判断属于哪种用户;
也可以增加vip用户,在普通用户表里增加字段区分是否vip,或者单独建表存vip用户信息。
在这里插入图片描述

中型系统

稍微大点的系统其中角色很多种,不止上面提到的3种,可能有几十种,这时候就需要单独建表保存所有角色,然后每个角色可以配置多个权限,达到对系统中模块的权限划分。
在每个模块中具体按钮或者页面,总之就是功能的入口处会判断当前角色是否有权限来决定是否让用户进入功能。
在这里插入图片描述

复杂系统

最复杂的系统与中型系统主要区别就是,可能每个用户拥有的角色数量不同,身兼多职,就需要多个模块的权限,
使用用户角色表、角色权限表关联查出拥有的权限;
可能个别用户拥有个别模块的这种特殊权限。
两种权限union起来就是该用户所有权限。
与中型系统表设计最大重点区别就是增加了《用户角色表》来保证单个用户可以拥有多个角色;增加了《角色权限表》保证单个用户的特护权限。
在这里插入图片描述

流程变更表设计

假设有个填写个人履历流程(或者叫电子流,类似一个申请表,要逐级递交上去,层层审批的过程);
流程有一个唯一id,以及其他业务数据,数据库表中数据例如:

order_id   name    birthday   ....
p0001  Alice  2022-01-24   ....

填写粗心数据有误,就需要有一个变更流程;变更生日数据时大致类似:

order_id   name    birthday   ....
p0001  Alice  2022-01-23   ....

问题就是,要保留变更前后的所有数据,不能直接update数据库数据。

第1种方法:
变更流程是一种新的独立的流程,数据如下:注意独立流程,单号就不一样了,c开头

order_id   name    new-birthday    old-birthday   ....
c0001  Alice  2022-01-23    2022-01-23   ....

这种可以达到目的,但是一条记录数据字段有上百个呢,每一个都要建立新的字段xxx-new xxx-old吗?

第2种方法:

order_id   name    date  ....   last_order_id   单号还是老格式,p开头
p0001  Alice  2022-01-23  .... c0001

本条数据保存的内容与请假流程一致, 公用一个表,新加一个字段 last_id 来关联 填写个人履历流程,这样只需要一个字段,就可以保存关联关系,数据也是最小化

第3种方法:
如果变更了10次呢,这样方法2就形成找父关系的关系链,数据一多,sql难写,维护难,各种问题;
所以此时 数据冗余 换取 逻辑清晰
变更表 不和 填写个人履历流程表 还是不共用,建立新表,数据如下:

id     name     birthday     order_version
c0001    Alice    2022-01-24     old
c0001    Alice    2022-01-23     v1

这样通过变更单号就找到2条,通过order_version区分谁是原始数据,谁是变更数据,变更多次的话,版本号累加即可:

id     name     birthday     ....    order_version
c0001    Alice    2022-01-24     ...    old
c0001    Alice    2022-01-23     ...    v1
c0001    Alice    2022-01-22     ...    v2

回过头再来看,数据可能存了好多,name字段十分数据冗余,但是找关系,写逻辑很清晰呀,这就是 数据冗余 换取 逻辑清晰,当然也可以反过来。

Logo

快速构建 Web 应用程序

更多推荐