数据库设计是信息系统设计的基础,一个好的数据库设计在满足软件需求之外,还要易维护、易扩充等等。
作为一个好的数据库应该满足以下几点(作者的观点,意见不同者可以留言讨论)
- 首先要满足用户的需求
- 其次要便于维护和扩充
- 数据库设计要具有可读性
- 能满足空间和设计的要求
- 可以简化业务逻辑设计
接下来说一下本文主要讲的一次数据库设计缺陷,导致用户操作之后,改变了之前存储的数据,为什么会导致这种结果呢?
这是一个简单的活动管理平台,在后台可以添加、编辑活动类型,如下图
主要是关于
上图是编辑页面,当完成编辑功能之后,在数据库表中可以看到更改的信息:
比如将之前的“高峰论坛”改成“大型会/城市会”,这样操作会导致什么结果呢,请看活动管理页面
之前发布的活动类型变成了大型会/城市会,导致之前发布的活动信息类型错误,那么想要恢复数据怎么搞呢,下面我们看看活动信息表:
该表中之存储了活动类型,其实在后台修改掉活动类型而导致活动信息类型改变之后,我们就能猜到这张表的数据结构,其实这种设计模式无可厚非,加强了表之间的关联,减少了数据冗余,节省了存储空间,但导致的后果就是在后台一个小小的修改,改变了之前整个数据(首先说明,数据库不是作者设计的)。用户为什么没事会想要去修改活动类型呢?原来是想要按照这种顺序导出活动信息报表。
清楚了用户的需求之后,接下来要做两件事情:
首先恢复之前的数据,其次数据库修改;
想要恢复之前活动信息的类型,只能对照活动类型id,结合之前用户下载活动信息报告,对照活动类型名称,在数据库中对活动类型表进行修改;
虽然数据恢复了,但是这种隐患还依然存在,要想一劳永逸,就需要修改数据库,代码重构;
首先,我们在活动信息表中添加活动类型名称字段;
在前端提交活动信息的时候,接口直接将活动名称存储在活动信息表中,后台在查看活动信息的时候,不需要从活动类型表中提取活动类型名称字段,这样即便活动类型表中的名称发生了变化,后台页面显示的信息也不会改变,导出的报表也是正确的;
首先将新加的字段信息补全,如下:
UPDATE activity_info SET activity_type_name='大型会/城市会' WHERE activity_type_id='ee250f9799c64e4bb63f03c8aebb6dfb'
其次修改后台页面信息查询sql:
<select id="activityRegisterlist" resultType="com.bootdo.activityResgister.vo.InfoVo">
SELECT
a.`activity_id`,
a.`activity_name`,
a.`province`,
a.`office_place`,
a.`office_leader`,
a.`activity_type_name`,
a.`activity_type_id`,
a.`activity_place`,
DATE_FORMAT(a.`activity_time`,"%Y-%m-%d") activityTime,
a.`person_num`,
a.`activity_sum`,
a.office_leader,
b.`name` createName
FROM
activity_info a LEFT JOIN
sys_user b ON a.user_id=b.user_id
LEFT JOIN
activity_type_info c ON c.activity_type_id=a.activity_type_id
<where>
<if test="activityName != null and activityName != ''"> and activity_name like CONCAT(CONCAT('%',#{activityName},'%')) </if>
<if test="activityId != null and activityId != ''"> and activity_id = #{activityId} </if>
<if test="province != null and province != ''"> and province = #{province} </if>
<if test="officePlace != null and officePlace != ''"> and office_place = #{officePlace} </if>
<if test="activityTypeName != null and activityTypeName != ''"> and activity_type_name = #{activityTypeName} </if>
<if test="activityTypeId != null and activityTypeId != ''"> and activity_type_id = #{activityTypeId} </if>
<if test="activityPlace != null and activityPlace != ''"> and activity_place = #{activityPlace}</if>
<if test="activityTime != null and activityTime != ''"> </if>
<if test="personNum != null and personNum != ''"> and person_num = #{personNum} </if>
<if test="activitySum != null and activitySum != ''"> and activity_sum = #{activitySum} </if>
<if test="createName != null and createName != ''"> and username = #{createName} </if>
<if test="startTime != null and startTime != ''"> and activity_time >= DATE_FORMAT(#{startTime},"%Y-%m-%d %T") </if>
<if test="endTime != null and endTime != ''"> and activity_time <= DATE_FORMAT(#{endTime},"%Y-%m-%d %T") </if>
and a.enable=1
</where>
<choose>
<when test="sort != null and sort.trim() != ''">
order by ${sort} ${order}
</when>
<otherwise>
order by activity_id desc
</otherwise>
</choose>
<if test="offset != null and limit != null">
limit #{offset}, #{limit}
</if>
</select>
做完这些之后,我们在系统中进行测试,将活动类型“沙龙会”改成“沙龙会1”,然后看活动类型为沙龙会的活动信息中的活动类型会不会变成“沙龙会1”,如下图
经过测试,修改活动类型名称不会对活动信息中的活动名称造成影响,至此整个bug修改完成