首页 > 解决方案 > 我想出了这个 SQL 结构来允许回滚和审计用户信息,这样就足够了吗?

问题描述

因此,我想出了一个想法,以一种始终可以回滚的方式存储我的用户信息和他们对自己的配置文件所做的更新(作为提供给用户的选项,用于审计和支持目的等)。 ) 同时提高 (?) 安全性并防止恶意活动。

我的想法是将用户的信息存储在行中,但绝不允许 API 后端删除或更新这些行,只插入应标记为“当前”数据行的新行。我创建了一个图形解释:

在此处输入图像描述 架构图像

我提出这个模型的潜在问题是用户可能过于频繁地更新信息,导致数据库膨胀(100 万用户,平均每个用户 5 次更新是 500 万个条目)。但是,为此我想出了通过分区将“当前”列中带有“假”的行分开的想法,它们不应该损害性能,并且会等待每隔一段时间进行清理。

我选择这个模型是否正确?有没有其他方法可以做这样的事情?

标签: mysqlsql

解决方案


我也会使用第二张桌子user_settings_history

创建设置时,将其user_settings_history连同创建时间的时间戳一起插入表中。然后还要更新表中的相同设置user_settings。中的每个用户将有一行user_settings,并且始终是当前设置。

因此,user_settings将始终具有当前设置,并且历史表将具有所有先前的设置集,与它们的创建日期相关联。

这简化了您对user_settings表的查询。您不必修改查询来过滤current您描述的标志列。您只知道您的应用程序的工作方式,其中的值user_settings被定义为当前值。

如果您担心user_settings_history表变得太大,时间戳列可以很容易地定期删除超过 180 天的行,或者任何您认为合适的天数。

顺便说一句,500 万行对于 MySQL 数据库来说并不算大。您希望您的查询在适当的情况下使用索引,但单独的大小并不是不利的。


推荐阅读