写项目时遇到的问题

一、关于数据库表的字段

在保养预警表中，

按照周期保养的设备有两种情况：1、未达到维保到期时生成预警记录--对应字段和值：status_time:0--预警时间内提醒保养；2、达到维保到期时生成预警记录--对应字段和值：status_time:1--保养超时。

按照时长保养的设备只有一种情况：达到保养预设时长--对应字段和值：status_time:1--设置为保养超时。

将两种保养方式在不同的时间段预警情况合并，解决两种保养方式预警时间冲突的问题。

为解决定时器更新数据时删除原来预警数据，引入最新数据的问题，引入了effective字段，功能有四：

1、设备保养预警页面查询时，他是其中一个重要条件；

2、在定时器更新数据时，按照不同保养方式查询，先将结果的每条记录的该字段设置为1，在继续执行service，根据条件筛选后的每条记录数据设置该字段为0，表明可以被预警页面查询到；

3、避免数据库大量删除

4、点击保养后他的状态更改为1，用于开启下一次保养生命周期

为解决设备的是否被保养问题，引入status字段：判断是否保养。

该字段不仅用于预警表页面查询，还用于在提交某设备保养表单--即结束该设备上一次保养生命周期，在这里还需要effective开启下一次保养生命周期。

此外，还添加了create_time字段，用户记录按时长保养的设备预警记录生成时间，目的是解决：

在前端页面按时长保养的设备预警记录的预警时间为空的问题。

二、关于理解保养管理功能的生命周期

在保养预警页面点击某台设备的保养后，会出现弹窗

填写数据点击确定后，开启该设备下次保养。

第一次添加设备开启该设备的保养生命周期，结束上次，开启下次保养都在这里完成。

保养记录的产生：某设备完成上一次保养

某设备的保养预警生成：有一个前提，深刻认识到前端用来与用户交互，上传表单等；后端处理业务逻辑，数据处理；数据库完成持久化，对单表或者多表操作（增删改查）等。

要使得预警表定时更新数据，则不适合在前端使用定时器，需要在后端处理，因此，代码实现针对生成预警记录成为核心。

三、关于前端页面优化，更具有观感度

合理调整页面格式，设置正确用户输入规则，尽量避免数据为空，正确书写前端提醒而避免造成用户认知歧义等。