这是一个创建于 751 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如在一个汽车维修的系统，维修公司员工会上传每个环节的维修内容和图片，用户可以看到员工的姓名、岗位（角色）、维修内容等。假如后续这个员工离职后，这个维修内容该怎么处理呢？
-
直接在公司员工表把这个员工删除，那员工写的这些维修内容该如何处理？
1.1 员工关联的维修内容也一起删除。（这个肯定不行，这些内容应该属于是公司的资产，用户也应该一直能看到）
1.2 维修内容表取消员工表 id 外键，删除时把维修内容表里的员工 id 设为
null，用户看到的维修内容员工显示为已离职。（个人觉得这个也不合理） -
在公司员工表里加一个
deleted_at字段，也就是软删除，其他任何数据都不作处理。假如后续这个员工再入职这个公司时，那这个员工之前的数据要不要恢复？2.1 直接在公司员工表再新建一条新数据，也就是一个新账户，不恢复原来的数据。
2.2 把
deleted_at设置为null，也就是恢复该员工原来的所有数据。（个人倾向于这个方案）
 | 1 AoEiuV020JP 2023-09-22 12:06:59 +08:00 我们公司的禅道系统里，离职了的员工名字会改成拼音首字母，不知道出于什么考虑， |
 | 2 wxw752 2023-09-22 12:17:56 +08:00 号冻结了就可以了 其他的不动 |
 | 3 Inzufu 2023-09-22 12:24:40 +08:00 via Android  3 如果是要考虑合规性，特别是欧盟的合规性，软删除肯定是不行，如果被员工知道了会被告。 还有根据 GDPR 的数据最小化原则，员工的姓名需要被匿名化或删除，就是以一个可识别字段代替员工的真实姓名。 我建议就是把离职员工名字里面的几个字拿*号抹掉，或者直接显示已离职，因为员工都已经离职了，即使让客户知道名字也没有用了。 |
 | 4 bk201 2023-09-22 12:25:36 +08:00 员工的一个状态，标记一下不行吗？ |
 | 5 512357301 2023-09-22 12:28:58 +08:00 via Android 1 我用 2.1 新入职就是新人了，为什么要重新启用？给个新 ID 就行了 |
 | 6 Daniel17 2023-09-22 12:30:27 +08:00 注账号之后再注册以前的数据还会存在？ |
 | 7 huntagain2008 2023-09-22 12:38:17 +08:00 记得酒店的饭卡充值系统是将离职的员工姓名改为 old_姓名 ，都是人力资源的不懂电脑的人独立操作的，数据库发现带有 a-zA-Z 字母开头的就 pass ，不做充值的操作。 |
 | 8 yinmin 2023-09-22 12:41:29 +08:00 1. 关于删除：如果有关联子信息，不允许删除 2. 加一个状态“在职/离职” 3. 关于再入职：如果 HR 要保留原工号，就把状态从离职改成在职即可；如果换工号做新员工入职，就再起一条新员工的记录 |
 | 9 jerrry OP @AoEiuV020JP 也就是软删除？ |
 | 11 coderluan 2023-09-22 13:04:29 +08:00 2 最开始就应该有个状态表示在职和离职，然后离职的情况下不产生新的数据，个人信息隐藏。 |
 | 12 kiml 2023-09-22 13:05:17 +08:00 via Android 离职了把所有关联数据转移为默认虚拟员工不就好了，然后写个转移 log 。至于员工数据去留，看业务需求啦 |
 | 13 vx007 2023-09-22 13:14:39 +08:00 via Android 我离职后，我的生辰八字，感情状态，岗位信息等还在人事系统公开可查 |
 | 14 xdao0324 2023-09-22 13:15:54 +08:00 做标记，例如原告在系统里面 显示 为张三，离职后加个字段 张三[已离职] |
| 15 Inzufu 2023-09-22 13:17:49 +08:00 via Android 3 @jerrry 是这样，不过还有一些细节问题： 首先任何国家的隐私法都允许保留员工的纳税记录、合同等法律文件以供今后出现法律纠纷时调用，不过这是公司其他部门该考虑到问题，和你关系不大。 其次，用户的数据在法律上分为内容数据和非内容数据，前者为用户产生的例如文件、聊天、工单回复等内容，而非内容数据指用户的个人信息、身份信息、登录密码等数据；一般来讲数据匿名化的重心在非内容数据上。 最后，数据匿名化并不是完全把员工的信息全部抹去，因为上面提到了法律允许保留一些法律文件，但如果采用真匿名处理员工数据，那么这些法律文件则不能和员工本身相关联，所以一般使用“假名化”代替匿名化处理数据，假名化也是 gdpr 所允许的。 最后的最后，如果你公司没有国外（或港澳台）员工，那么不用太多考虑这些问题，因为国内基本不管。 |
 | 16 tool2d 2023-09-22 13:21:36 +08:00 |
 | 17 Vindroid 2023-09-22 13:26:01 +08:00 软删除就好了，记录留着，谁知道什么时候会有需要调出来看下，也不占多少空间 |
 | 18 nzynzynzy 2023-09-22 14:57:29 +08:00 用员工号代替姓名，加一个状态：有效 = true/false ，再回来就继续修，或者启用一个新员工号就好了。 维修内容显示员工应该是“E0035 王强”，而不是“王强”，不然等你有俩王强时候就热闹了 |
 | 19 SenLief 2023-09-22 14:58:53 +08:00 可以借鉴一下企业微信的做法，该员工离职后，原有工作内容交接给下一位继任者。维修内容是属于公司和客户的，不属于员工的。 对于员工内部数据库应该标记离职，对应调取的权限应升级，对外保留账号不就好了。 |
 | 20 masterclock 2023-09-22 15:05:07 +08:00 “软删除” （置 deleted_at ）并不等于 “修改员工状态为离职” 共用一个字段很可能在一些情况下引发问题 |
 |
 | 22 openliucongbx 2023-09-22 16:04:11 +08:00 |
 | 23 openbsd 2023-09-22 18:37:33 +08:00 汽车维修这种可能涉及安全的，操作人员信息也要清除吗 ？ 参考施工单位，项目竣工 10 年后事故，还要追责承建和施工人员 |
| 25 jerrry OP @masterclock 谢谢提醒，离职用 resigned_at 可能更合适一下 |
 | 26 julyclyde 2023-09-23 18:23:26 +08:00 给你们讲个笑话： 当年美团某系统，资产的外键是人员的主键，离职即删人 然后资产也被删了 |
Select Language