OP
就一个后台系统，不存在多人协同的问题
emmm, 就是如果只做前端判断的话
A 打开了这个数据->修改了 A1 字段->还没保存的时候 B 也打开了这个数据, 修改了 B1 字段然后保存了->这时候 A 再保存
这样就会存一条 B 把 B1 字段修改了的日志和 A 把 A1 字段修改了的日志, 但是实际上如果没有特殊处理一般都是整个表单提交, 这时候 A 保存的时候会把 B1 字段覆盖, 所以能查到 B 的修改记录, 但是查不到 A 修改 B1 字段的记录, 而且 B1 字段还是原来的值, 但是这条记录跟日志的记录不一样, 你也很难查是什么问题, 所以还是尽量后端校验
展开 1 条评论
给我搞应激了，瞬间回到之前做的一个需求，要求记录一个列表中得字段变更记录，就是修改这个列表中得某个字段值时，要记录下来修改前是什么值，修改之后是什么值，是谁在什么时间修改的。一边做一边问候业务方八辈祖宗！
一开始我是拒绝的，但是拒绝的后果就是我直接被业务 BP 拉过去亲自给业务方领导解释为什么做不了！
解释之后，不行，我就要做！
最后还是做了，现在这个业务功能已经无人问津了，当初的业务方领导也早就离职了
挺好做的, 首先记录下要修改的这 3 条原始数据, 然后再记录下更新后的 3 条数据,
OP
我也是这么想的，但是后端说业务很复杂，做不了
按你的描述,这题真不难, 他可能就是不想写.
展开 1 条评论
后端说不知道修改了啥东西，那前端把修改前后的数据一起传给后端不就知道了吗。
他要是再提出其他做不了的原因，就再解决他的问题就是了。
实在不行你就说那我们一起去咨询下 XX 大佬（组长/经理）看看有啥办法没。
三条数据是三个字符串还是三段结构化的数据，我是这个需求的后端的话，也不会在后端做。大概率在产品层面上做，只能一条条的修改，修改完后前端提交，后端逐条记录。做是能做的，有什么必要吗？
OP
三个字符串，一起提交是产品设计的一个弹窗，操作便捷，现在就是一个弹窗一行行单独提交
是真的，实现不了
我觉得开发当中应该不存在能不能改，而是这个功能是一定要按这个步骤实现还是有别的办法，如果有别的办法那后端不实现是可以的，如果一定要这么实现那后端再怎么说应该也要实现，你现在这么说那就只是你自己想这么做，但是需求不强制，后端不做合理，你硬说他也只是你单方面说了。
但是也存在这么设计交互可能更合理，你公司后端混日子不想管，需求或者项目经理不强势，后面客户真操作不爽还是要改，但是你现在也没办法，感觉这样只能放平心态了，反正只要算你工时就行，而且都是 AI 改其实都还行。
没看你六楼回复，感觉你公司有这样后端，那你们这些项目应该都是噱头，并不能真正做事情，应该碰到点难的问题都处理不了，处理逻辑前后端都有是散的不集中，我觉得这就是垃圾项目。感觉你们公司很有可能就是图补贴的公司吧，项目是否真能产生价值应该不重要，感觉你有时间最好考虑尝试面试了，你公司要是不大或者没有很硬的靠山，很有可能说倒就倒
OP
那到不会，公司营收方面很硬，甚至年年增长，只是因为当前都是增加新需求，而新需求能有就够了，并不需要做的很好，因为这不是正常的私企项目，本帖的意思都是基于我个人的工作习惯，希望能用更好的方案来实现，但是人微言轻，所以在和站友们分享了之后心态也平了，至于重新找工作面试，说实话在当前城市并不乐观，而且是否能通过面试也与个人关系不是很大了，现在都是能干一天是一天，不过还是很感谢你能给出这么多的分析和建议
展开 1 条评论
发表一个评论
R保持
(就按你说的信息显然是假的, 但是也有可能是有其他限制
明细数据保存日志留存这个经典问题了, 其实就是麻烦,
但是简单也有简单的做法, 简单的做法就是当他全都更新了, 全量保存日志, 缺点是查也不好查, 需要的硬盘也大
麻烦点的就把现在数据库的数据拉出来逐一对比, 把修改过的字段进行保存, 缺点是保存的时候还要把旧数据拉出来一次, 比较也需要消耗服务器性能, 性能比较吃紧而且还有大量更新的的可能就没法用这个方法
至于前端记录修改的字段就不说了, 这个可能多人协同的时候会出现问题, 不建议这么做