这种数据库审计方法是否存在缺陷

时间:2014-10-27 15:27:45

标签: logging database-design audit

我正在设计一个数据库,并希望获得所有更改值的审核信息。我想验证我的方法 - 如果可能有任何不利因素,我已经完成了现有的问题,并尝试了一些。此链接总结了几乎所有Database design for audit logging

以下是我的想法:一个公用表,例如audit_info,其中包含以下列

- > ID(已生成)

- >表名

- >时间戳

- > beforeHashedValue - 这将在更改哈希值之前获得所有信息

- > afterHashedValue - 这将包含所有信息用键更改哈希后

如何运作

- >每当值发生变化时,捕获整行,加密并写入审计表

- >以异步模式写入审计表 - 通过异步模式我的意思是,在更新存储当前数据的图像之前,如果事务成功,则将其提供给某些将执行加密和更新表的线程

- >在主表中使用唯一ID作为外键,将其存储为逗号单独的字符串以进行多次更新

- >要检索值,请按表查询并按时间戳排序以获取历史值

- >解密每一行以获取时间轴数据

优点:

- >我认为这很简单

- >不会影响主要表格

- >每个表都没有混乱,主表只需要将外键存储到审计行(目前我一直在为每个表存储审计信息,这已成为维护的噩梦)

- >对于多次审核,可以维护逗号单独的列表,该列表可用于获取审核值

我能想到的一些缺点是:

- >加密和解密可能需要时间

- >非常大的物体怎么样?例如文字,blob?加密的行为如何?

- >如果需要实时审核,可能会导致性能瓶颈!

- >需要逻辑将其映射回基于域模型的表名

鉴于:

我的桌子没有任何BLOB,但是最大文字说3k-4k字

无需实时审核,

此方法有什么主要劣势吗?

0 个答案:

没有答案