3 回答
TA贡献1877条经验 获得超1个赞
对于评论来说这可能太长了。
根据我对 GDPR 的了解,90 天似乎有点激进。
也就是说,你所做的事情是相当危险的,至少从分析和财务的角度来看是这样。了解客户在一段时间内进行了多次购买可能非常重要。GDPR 非常明确地指出,您可以保留有关活跃(和最近以前的)客户的历史信息。(当然,我不是律师,即使我是,您也应该对网络上的免费咨询感到非常怀疑。)
也就是说,您的sales桌子应该设计为符合隐私要求。如何?将客户信息存储在不同的表中。
因此,该sales表应如下所示:
| ID | CUSTOMERID | PRODUCT | DATE |
| 1 | 1 | 4816419 | 2019-12-25 10:26:19 |
| 2 | 2 | 6662341 | 2019-11-23 10:26:19 |
| 3 | 3 | 4816419 | 2019-05-05 10:26:19 |
从隐私角度来看,这张表完全没问题,假设该表CUSTOMERID严格在内部使用。
然后你应该有一个CUSTOMERS表:
| CUSTOMERID | CUSTOMER | EMAIL | LASTSALEDATE |
| 1 | Ken James | ken.jam@example.com | 2019-12-25 10:26:19 |
| 2 | Amy Wen | amywen@example.com | 2019-11-23 10:26:19 |
| 3 | Chris Pet | chripet@example.com | 2019-05-05 10:26:19 |
您可以在该表中将姓名、地址、电子邮件、电话号码等替换为NULL值(或者'XXXX'如果您愿意)。
这种结构允许您维护重复购买和购买日期等的内部历史记录 - 即使数据已匿名。通过将所有 PII 放在一处,可以更轻松地维护、审核并确保其满足 GDPR 和其他隐私法的要求。
TA贡献1850条经验 获得超11个赞
您可以执行以下操作:
UPDATE *table_name*
SET CUSTUMER = 'xxxxxxx', EMAIL = 'xxxxxxx'
WHERE CURRENT_DATE() - DATE > 90;
CURRENT_DATE() 返回当前日期的日期(您也可以使用 GETDATE() 代替 CURRENT_DATE())
TA贡献1852条经验 获得超1个赞
您可以使用内置的调度程序。
但必须开启
CREATE EVENT event1
ON SCHEDULE EVERY '1' DAY
STARTS '2020-08-17 00:00:01' -- should be in the future
DO
UPDATE sales
SET EMAIL = 'xxxxxxxx', CUSTOMER = 'xxxxxxxx'
WHERE EMAIL <> 'xxxxxxxx' AND CUSTOMER <> 'xxxxxxxx' AND `DATE` < DATE_ADD(NOW(), INTERVAL -90 DAY);
- 3 回答
- 0 关注
- 154 浏览
添加回答
举报