Ruby on Rails API删除帐户，但不要丢失所有预订系统
数据保护和GDPR有很多变化。我不确定哪种方法是我开发它的正确方法。
我之所以寻求建议，是因为由于删除要求扩展＆nbsp; https：//developer..apple.com/news/？id = i71db0mv，
我们正在使用ror api。而且我们有移动应用程序，但我们没有删除帐户，只有停用帐户，我们需要保留有关预订历史记录的记录。
我在想这样的事情。
使用Old User_id，名字，第二个名称，电子邮件和预订slug创建一个新的表“ old_user_table”。
它将允许所有进行以前预订的用户。并在应用程序中删除其用户ID。在过去的5 - 10年中，我们需要保留所有记录以进行审计目的。
使用此应用程序，用户但从未预订的用户设置，则用户不会转移到“ old_user_table”，因为用户无需预订。
有意义吗？这样的东西？还是您有更好的选择？
（仅供参考，我不是开发人员，但我想确保在与Ruby Developers会面之前，我有更好的知识或更好的案例）。
There is a lot of changing with Data Protection and GDPR. I am not sure which is the right method for me to develop it.
The reason I was looking for advice because of the new Apply policy on account of deletion requirements extended https://developer.apple.com/news/?id=i71db0mv
We are using ROR API. and we have mobile App but we don’t have deletion account, only Deactivate Account cos we need to keep a record on booking history.
I was thinking something like that.
Create a new table “old_user_table” with old user_id, first name, second name, email, and booking slug.
It will allow keep all users who did previous booking. And deleted their user ID in the app. We need to keep all records for booking for audit purpose in the last 5-10 years in the app.
The user setup with this app, the user but never booking, then the user will not transfer to “old_user_table” cos the user booking nothing.
Does it make sense? Something like that? Or do you have a better alternative?
(FYI I’m not RoR Developer but I want to make sure I have better knowledge or better case before meeting with Ruby developers & IOS developer).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
该方法不会符合GDPR，因为您要保留 pii pii pii 在Old_表中。
如果要保留旧的预订，我将替换一些与真实用户没有链接的新的随机生成的UUID，然后从数据库中删除用户。
That approach won't be GDPR compliant since you are keeping PII in the old_ table.
If you want to keep the old bookings I would replace the user_id for some new random generated UUID that has no link with the real user, and then remove the user from the database.