首先，我在网上发现了很多关于这个问题的讨论，但我真的对提出的解决方案持怀疑态度，主要是因为它们大多来自4年前GDPR还很新颖的时候，也因为它们相互矛盾。
为了符合GDPR，我们需要在用户要求时完全删除用户的个人信息(电子邮件、姓名、地址等(。
在我们的系统中，我们有User表和其他表，例如Training和Session。
Training与User有ManyToMany关系，Session表有一个User_id字段，该字段是User表的外键。此外，Session有一个training_id字段，该字段也是训练的外键
我想删除用户中包含的用户个人信息，但我希望能够将他们的数据保存在会话中用于统计和日志目的。
我知道硬删除不是办法，fk约束会有问题，即使我可以使用Null，也不建议使用。我经常看到的建议是在User表上添加一个标志，指示用户是否被删除(is_delete(，并在我的业务逻辑中适当地使用它。IMO，单凭这一点并不能真正解决GDPR的问题，因为用户的信息仍在数据库中，这可能会给你的审计带来麻烦，我很惊讶这种回答在大多数话题中都获得了支持。
我想做的是，添加is_delete标志，但也用假数据或空数据更新用户行，以清除所有用户个人信息。所以我会有这样的东西：
| ID | 电子邮件 | 姓名姓氏地址 | 已删除||
|---|---|---|---|---|
| 1 | "quot | 匿名 | <td"">"> | 真 |
你说得对。更新具有个人身份信息的行是在不破坏数据库约束的情况下实现这一点的方法。您可能想要将PII列中的一个更改为说"；在(日期-时间("；以防某些审计员希望看到您遵守这些要求的证据。
将更改筛选到所有备份需要一段时间。除了确保不会保留太早以前的旧备份外，在操作上对此无能为力。
如果将PII用作主键、唯一键或约束键，则存在问题。例如，如果使用电子邮件地址作为用户信息的关键字，则可能需要将这些列中的值替换为随机生成的文本字符串，以删除数据并保持唯一性。您必须以保留约束的方式来执行此操作。
不要忘记，您的web服务器日志很可能允许您根据用户ID查找用户的IP地址。请确保您设置了日志保留策略(十天？(，并通过自动删除来强制执行。
让你的政策说"；可能需要长达三十天的时间才能完全删除"让您的工作流有时间影响服务器日志和备份。
如果用户要求您删除所有数据，然后返回使用您的服务，请以从未见过的用户身份处理这些数据。如果你能发现你以前见过他们，那么你显然没有在被要求时删除他们的所有PII。