OP
就一个后台系统，不存在多人协同的问题
emmm, 就是如果只做前端判断的话
A 打开了这个数据->修改了 A1 字段->还没保存的时候 B 也打开了这个数据, 修改了 B1 字段然后保存了->这时候 A 再保存
这样就会存一条 B 把 B1 字段修改了的日志和 A 把 A1 字段修改了的日志, 但是实际上如果没有特殊处理一般都是整个表单提交, 这时候 A 保存的时候会把 B1 字段覆盖, 所以能查到 B 的修改记录, 但是查不到 A 修改 B1 字段的记录, 而且 B1 字段还是原来的值, 但是这条记录跟日志的记录不一样, 你也很难查是什么问题, 所以还是尽量后端校验
展开 1 条评论
给我搞应激了，瞬间回到之前做的一个需求，要求记录一个列表中得字段变更记录，就是修改这个列表中得某个字段值时，要记录下来修改前是什么值，修改之后是什么值，是谁在什么时间修改的。一边做一边问候业务方八辈祖宗！
一开始我是拒绝的，但是拒绝的后果就是我直接被业务 BP 拉过去亲自给业务方领导解释为什么做不了！
解释之后，不行，我就要做！
最后还是做了，现在这个业务功能已经无人问津了，当初的业务方领导也早就离职了
挺好做的, 首先记录下要修改的这 3 条原始数据, 然后再记录下更新后的 3 条数据,
OP
我也是这么想的，但是后端说业务很复杂，做不了
发表一个评论
R保持
(就按你说的信息显然是假的, 但是也有可能是有其他限制
明细数据保存日志留存这个经典问题了, 其实就是麻烦,
但是简单也有简单的做法, 简单的做法就是当他全都更新了, 全量保存日志, 缺点是查也不好查, 需要的硬盘也大
麻烦点的就把现在数据库的数据拉出来逐一对比, 把修改过的字段进行保存, 缺点是保存的时候还要把旧数据拉出来一次, 比较也需要消耗服务器性能, 性能比较吃紧而且还有大量更新的的可能就没法用这个方法
至于前端记录修改的字段就不说了, 这个可能多人协同的时候会出现问题, 不建议这么做