项目实训工作记录

后端及数据库开发总体计划

本次项目的后端部分搭建,以数据库为基础,以API服务为导向,搭建一个围绕微服务展开的、可拓展的、分布式的后端及数据库。

1、完成API接口文档

2、完成数据库设计

2.1 项目初步概念ER图

初步概念

2.2 实体关系图

本次项目设计三种用户类型(学生、老师、管理员),以及一个可操作的实体(项目)。
实体之间的关系

2.3 学生信息的数据表

学生用户信息表

列名数据类型长度小数位数是否可为NULL说明
UIDString32主码
UNameString32用户姓名
USexInt10为女性.1为男性.2为未知
UCollegeString32大学
UGradeString32年级
UEmailString256邮箱
UNumberInt16手机号.考虑外国的

用户信息表保留可拓展性。

学生用户密码表

列名数据类型长度小数位数是否可为NULL说明
UIDString32主码
UPasswordString32用户口令.非明文

对用户的密码进行独立设表进行维护。将密码与基本信息区分开可以从根本上防止密码外泄,同时可以有效地区分开对密码进行改查操作和其他操作。

学生在线用户表

列名数据类型长度小数位数是否可为NULL说明
UIDString32主码
UOLcodeString32在线用户值.用于请求API

当用户登录时,我们会返回给用户一个独一无二的有时效性的在线值。用户接下来对API的请求操作都必须附带该在线值,否则我们无法认定该请求是否为用户本人请求的。

2.4 项目信息类型的数据表

项目信息表

列名数据类型长度小数位数是否可为NULL说明
PIDString32主码
PNameString32项目名称
PInstructionString256项目描述
PCreateTime项目创建时间
PDirectorString32项目负责人UID

项目成员表

列名数据类型长度小数位数是否可为NULL说明
PIDString32主码
PMember项目成员

2.5 文件系统的数据表

文件信息表

列名数据类型长度小数位数是否可为NULL说明
FIDString32主码
FNameString32文件真实名称
PIDString32文件隶属项目的PID

文件夹信息表

列名数据类型长度小数位数是否可为NULL说明
FFIDString32主码
FFNameString32文件夹真实名称
PIDString32文件夹隶属项目的PID

文件目录表

列名数据类型长度小数位数是否可为NULL说明
PIDString32主码
ParentIDString32父节点的ID
IDString32该节点的ID

2.6 任务系统的数据表

任务信息表

列名数据类型长度小数位数是否可为NULL说明
TIDString32主码
PIDString32所属项目PID
TNameString32任务名
TInstructionString32任务描述
TCreateTime任务创建时间
TEndTime任务截止时间
TDirectorString32任务负责人UID
TIdentifierString32任务标识符

任务附件表

列名数据类型长度小数位数是否可为NULL说明
TIDString32主码
FIDString32附件为共享文件空间内的文件时
LFIDString32附件为新上传的本地文件时

任务关系表

列名数据类型长度小数位数是否可为NULL说明
TIDString32主码
PIDString32所属项目PID
ParentTIDString32父节点的TID

2.7 博客系统的数据表

博客信息表

列名数据类型长度小数位数是否可为NULL说明
BFIDString32主码
PIDString32所属项目PID
UIDString32创建者
BCreateTime博客创建时间
BEditTime博客最近修改时间

博客权限表

列名数据类型长度小数位数是否可为NULL说明
BFIDString32主码
ReadString32被赋予读权限的UID
WriteString32被赋予写权限的UID

3、后端服务的逻辑结构

3.1 登录系统

3.2 个人信息系统

3.3 文件系统

文件系统的构建分为数据库表和文件存储空间。
数据库表存储项目的文件系统结构及其路径,文件存储空间则负责将后端接收到的文件进行重命名,并存放在存储空间内。
具体流程如图:
在这里插入图片描述
当用户在前端查看文件目录时,后端仅需将文件系统结构路径发给前端。当需要下载时,则查表找到对应的文件,并改名后发回给前端。

工作日志

2021-3-28

       到目前为止对数据库的初步设计是已经完成了。接下来就是以SSM框架为基础,展开DAO层的编写工作。对于一些必要的功能,甚至要提供DTO层。在数据库设计的设想过程中,已经考虑到文件系统和任务系统未来实现的很多种方式,基本上都是在围绕性能和复杂度进行权衡,对于没有过多项目经验的我们来说是一次积累经验的机会。
       在对文件系统的构造方式的探索中,我们小组尝试了很多种方案,但是大部分的效果都不太好。一个过于冗杂耦合的资源管理系统肯定是有很多弊端的,因此首要考虑应该是从功能角度出发,将查询与上传下载的功能分开,分开进行会让性能和效率都会有所提升。因此创造性地提出了将文件统一存储,用唯一标识符进行区分,文件路径仅仅体现在数据库的表中这样一个方案。
       任务系统的设计在后续发展过程中会产生很多种方案。因此我们的首要设计原则应该是抓住任务系统最核心的功能进行开发 ,同时保留相当大的可拓展性,保证在未来迭代中出现新的特征时可以在不影响原有系统的情况下进行增量。同时在对核心任务系统的功能进行数据库设计时,我们发现它也需要特殊的数据结构来保证可拓展性,在前后端的交互上要考虑很多问题。
       对于通知系统则有所保留。目前因为通知系统的准确规则尚未明确,因此通知系统应能实现特殊条件触发和自定义通知两种形式,保证在产品迭代过程中保有选择。
       总体上看,接下来可以进入到DAO层的设计了。DAO层的存在是为了把Service层和数据库进行解耦,使其中某一方改变了规则而不会影响到另一方,因此这一层的设计必须十分系统客观。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页