之前设计的数据库最大的问题在于不能把过去某个时间的状态信息显示出来,只是记录了单个信息的操作记录。所以这样就会出现一些问题,例如,上个月一个班里面有32个人,前几天有一个人退学了,那么现在查询的这个班级的信息就是31个人,之前的32个人得信息就没有办法显示出来,这是历史,但是我们没有办法显示出来。
方案一:从学生的角度出发,系统中的机构都是为了学生而设置的,相当于是为学生搭起来的架子,因此学生的信息是可以随意更改的,在处理类似班级和专业的记录的时候,秉承着:和其他实体类有关系或者下面包含学生等元素,那么就认为是有意义的,就不能执行删除等操作。只有没有任何联系,其下包含的元素都不存在的时候,就可以认为这条记录是无意义的,同时可以删除。出发点在于:以学生为中心,主要的问题就是学生的变动会影响之前留存的信息,没有真正实现历史数据的保留。(被否决)
方案二:类似于档案管理,新建和原来的数据库一样的结构,一个记录做了更改,和其相关的联系都做一次记录并加上时间戳。这样的思路,可以实现在过去的某一个时间的信息展示,可以复原出来,根据时间来卡。不过,时间有了,但是如何找到确实是当时的那条相关联的信息是一个问题,毕竟数据库处理数据也会有一定的时间,完全依靠时间来也是不现实的。(被否决)
最终方案:数据库中同样的表都是由两张,一个存储当前最新的状态信息,一个表记录信息的变更。
方案一:从学生的角度出发,系统中的机构都是为了学生而设置的,相当于是为学生搭起来的架子,因此学生的信息是可以随意更改的,在处理类似班级和专业的记录的时候,秉承着:和其他实体类有关系或者下面包含学生等元素,那么就认为是有意义的,就不能执行删除等操作。只有没有任何联系,其下包含的元素都不存在的时候,就可以认为这条记录是无意义的,同时可以删除。出发点在于:以学生为中心,主要的问题就是学生的变动会影响之前留存的信息,没有真正实现历史数据的保留。(被否决)
方案二:类似于档案管理,新建和原来的数据库一样的结构,一个记录做了更改,和其相关的联系都做一次记录并加上时间戳。这样的思路,可以实现在过去的某一个时间的信息展示,可以复原出来,根据时间来卡。不过,时间有了,但是如何找到确实是当时的那条相关联的信息是一个问题,毕竟数据库处理数据也会有一定的时间,完全依靠时间来也是不现实的。(被否决)
最终方案:数据库中同样的表都是由两张,一个存储当前最新的状态信息,一个表记录信息的变更。