证件管理系统开发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架构中最简单的单体架构,并没有用到诸如高并发、高可用的架构体系。但是系统开发是没有最完美的架构的,只有最合适的架构,在充分考虑时间成本、硬件成本、开发成本和使用度上,目前这套设计足够公司内部的简单使用了。
至此证件管理系统开发到此结束,谢谢各位的观看。

1196

被折叠的 条评论
为什么被折叠?



