证件管理系统开发2:数据库设计
0、前言
在上一篇中我们明确了证件管理系统的具体需求,接下来我们将正式开始开发,在后续的几篇系列文章中,我将从数据库设计、后端开发、前端PC开发、前端APP开发以及总结优化一一展开介绍。
本篇将详细介绍数据库设计,由于不可描述的原因本篇内容将会只提供核心字段。
1、数据库表清单
根据之前分析的证件管理系统需求,我们初步设计出以下数据库表
库表名称 | 中文名称 | 备注 |
---|---|---|
user | 用户表 | |
cert | 证件表 | |
cert_edit | 证件修改表 | 保存证件新增/修改后的信息,待审核通过后更新至证件表 |
cert_audit | 证件审核表 | |
cert_brrow | 证件借用表 | 证件借用/归还申请信息和审核信息的记录表 |
cert_message | 消息表 | |
cert_profe | 专业表 | 证件相关配置表 |
cert_typ | 类型表 | 证件相关配置表 |
cert_profe_type | 专业类型表 |
1.1、user 用户表
字段名称 | 中文 |
---|---|
id | |
name | 名称 |
dept | 部门 |
1.2、cert 证件表
字段名称 | 中文 | 备注 |
---|---|---|
id | 证件id | |
name | 证件名称 | |
user_id | 证件人员 | |
type_id | 证件类型id | 关联cert_type表 |
profe_id | 证件专业id | 关联cert_profe表 |
start_date | 证件生效日期 | |
end_date | 证件失效日期 | |
borrow | 证件借用状态:0不可借用,1可借用,2借用中 | |
attachment | 附件存储地址 | |
… | … | 根据实际情况添加字段 |
1.3、cert_edit 证件修改表
cert_edit表的字段和cert 证件表完全一样,区别只在于cert表是经过审核的数据
字段名称 | 中文 | 备注 |
---|---|---|
id | 证件id | |
name | 证件名称 | |
user_id | 证件人员 | |
type_id | 证件类型id | 关联cert_type表 |
profe_id | 证件专业id | 关联cert_profe表 |
start_date | 证件生效日期 | |
end_date | 证件失效日期 | |
borrow | 证件借用状态:0不可借用,1可借用,2借用中 | |
attachment | 附件存储地址 | |
… | … | 根据实际情况添加字段 |
1.4、cert_audit 证件审核表
字段名称 | 中文 | 备注 |
---|---|---|
id | 审核id | |
cert_id | 证件id | |
aduit_id | 审核人员id | |
result | 审核结果 | 0通过、1不通过 |
describe | 审核描述 | |
… | … | 根据实际情况添加字段 |
1.5、cert_brrow 证件借用表
字段名称 | 中文 | 备注 |
---|---|---|
id | 借还id | |
cert_id | 证件id | |
describe | 借用申请描述 | |
borrow_aduit_id | 借用审核人员id | |
borrow_result | 借用审核结果 | 0通过、1不通过 |
borrow_describe | 借用审核描述 | |
return_aduit_id | 借用审核人员id | |
return_result | 借用审核结果 | 0通过、1不通过 |
return_describe | 借用审核描述 | |
… | … | 根据实际情况添加字段 |
1.6、cert_message 消息表
字段名称 | 中文 | 备注 |
---|---|---|
id | 消息id | |
user_id | 接收消息人员id | |
type | 消息状态:0未读,1已读 | |
message | 消息内容 | |
… | … | 根据实际情况添加字段 |
1.7、cert_profe/cert_typ/cert_profe_type 证件相关配置表
cert_profe和cert_typ表结构基本一致,均是以树结构形式存储,parent_id=0时为第一层数据
字段名称 | 中文 | 备注 |
---|---|---|
id | id | |
parent_id | 父节点id | |
name | 名称 | |
… | … | 根据实际情况添加字段 |
cert_profe_type表,由于类型与专业存在关联关系,即A类型对应B、C专业,故创建对应的关系表
| 字段名称 | 中文 |
|–|–|–|
| id | id |
| type_id|类型id |
| profe_id| 专业id|
2、总体架构
由于该系统使用频率低、数据量少、用户量也不多,但为了缩减工期、易于扩展、便于二次开发,所以综合上述因素采用当下主流的框架,前后端框架分别为:
后端mysql + spring boot;
前端PC端vue + element UI 框架;
前端APP端vue + uni-app + uview UI 框架
总结
从上述表设计能看出该证件管理系统的的表设计相对简单,没有动态增添证件字段和复杂的流程设。整体架构也只是采用目前主流spring boot架构中最简单的单体架构,并没有用到诸如高并发、高可用的架构体系。但是系统开发是没有最完美的架构的,只有最合适的架构,在充分考虑时间成本、硬件成本、开发成本和使用度上,目前这套设计足够公司内部的简单使用了。
至此证件管理系统开发到此结束,谢谢各位的观看。