目录
一、申请时效性介绍
用户每一次申请对数据库的查询或插入操作都是有时效性的。在有效期内，用户可以进行对所申请插入或查询操作。但是一旦超过失效时间，用户的一切操作都会被禁止。无法查看密钥更无法跳转到操作页面。
昨天写了项目总结，又复盘了一下申请时效性逻辑。方便之后查看和修改。
二、申请时效性保障逻辑
1.系统数据库设计
申请详情表：
每个申请都具有开始时间：atime,持续时间：stime以及失效时间：etime。
每个申请具有失效位：isend。
失效位的取值及定义：
| 失效位 | 定义 |
| 失效位为2 | 表示管理员通过申请且用户未查看密钥 |
| 失效位为1 | 表示该申请已失效 |
| 失效位为0 | 表示申请未失效 |
2.时效性保障逻辑
- 用户提交申请，管理员进行申请审核。当管理员通过用户申请时，修改申请的失效位为2
- 在用户端，用户点击查看申请详情时要进行失效位和失效时间的判断：
- 失效位为2时，为用户首次点击查看详情来查看已通过的本条申请，此申请 还没有开始启用，在详情页面失效时间显示为“请先查看密钥”，跳转操作按钮点击也会提示请先查看密钥。当用户点击查看密钥时，首先将失效位修改为0，同时把会比较当前时间和失效时间，如果失效，修改该条申请失效位为1，同时失效时间改为“该申请已失效”，点击跳转操作按钮也会提示已失效；如果未失效，就更新失效时间到页面上，然后继续操作。用户点击跳转操作界面时，同时也会再次进行失效位和失效时间的判断：如果失效位为1则没有办法跳转；失效位为0，比较当前时间和失效时间，如果已失效，更新失效位为1，如果未失效，就进行跳转。用户在操作界面进行插入语句或查询语句的输入，在点击提交的时候，同样也需要进行失效位和失效时间的判断，如果已失效，更新失效位为1，并提示已失效，重新进行申请；如果未失效，就继续操作。
- 失效位为0时，比较当前时间和失效时间，如果已失效则修改失效位为1，并将失效时间改为“该申请已失效”，同时跳转按钮也会提示已失效；如果未失效，则继续操作。点击查看密钥按钮，同样进行失效位和失效时间的判断，如果失效位为1时，提示已失效，同时更新失效时间为“该申请已失效”，同时点击跳转界面也会提示失效；如果失效位为0，比较当前时间和失效时间，如果失效，修改该条申请失效位为1，同时失效时间改为“该申请已失效”，点击跳转操作按钮也会提示已失效；如果未失效，就可以继续操作。用户点击跳转操作界面时，同时也会再次进行失效位和失效时间的判断：如果失效位为1则没有办法跳转；失效位为0，比较当前时间和失效时间，如果已失效，更新失效位为1，如果未失效，就进行跳转。用户在操作界面进行插入语句或查询语句的输入，在点击提交的时候，同样也需要进行失效位和失效时间的判断，如果已失效，更新失效位为1，并提示已失效，重新进行申请；如果未失效，就继续操作。
- 失效位为1时，更新失效时间为“该申请已失效”，同时查看密钥和跳转操作按钮都会提示申请失效。
实现效果图（已通过的申请详情页同时已经点击查看过密钥）：
3.时效性保证的实现逻辑流程图
上面的逻辑介绍是根据点击详情页面时的失效位和失效时间情况所作出的分类。
因为比较繁复，所以做了个逻辑流程图方便理解和代码实现。
总结
以上就是时效性实现的逻辑。