每次我需要设计一个新的数据库时,我都会花一些时间考虑如何设置数据库模式来保存更改的审核日志.
这里已经提出了一些问题,但我不同意所有场景都有一个最好的方法:
我还偶然发现了这篇关于维护数据库更改日志的有趣文章,该文章试图列出每种方法的优缺点.它写得很好并且有很多有趣的信息,但它使我的决定更加困难.
我的问题是:是否有一个我可以使用的参考,可能是一本书或类似决策树的东西,我可以参考决定我应该根据一些输入变量去哪种方式,例如:
我知道的方法是:
1.为创建和修改的日期和用户添加列
表格示例:
主要缺点:我们失去了修改的历史.提交后无法回滚.
2.仅插入表格
表格示例:
主要缺点:如何保持外键最新？需要巨大的空间
3.为每个表创建单独的历史记录表
历史表示例:
主要缺点:需要复制所有审计表.如果架构发生更改,则还需要迁移所有日志.
4.为所有表创建合并历史记录表
历史表示例:
主要缺点:如果需要,我能否轻松重建记录(回滚)？new_value列需要是一个巨大的字符串,因此它可以支持所有不同的列类型.
人们在相当复杂的数据库中维护数据更改历史记录的成功策略是什么？我经常使用和开发的应用程序之一可以真正受益于更全面的跟踪记录随时间变化的方式.例如,现在记录可以具有多个时间戳和修改的用户字段,但是我们目前没有用于记录多个更改的方案,例如,如果回滚操作.在完美的世界中,可以在每次保存之后重建记录,等等.
关于DB的一些信息:
我目前正在玩我的数据库中有一些表的历史表.基本上我有主表和该表的副本,其中包含修改日期和操作列,用于存储执行的操作,例如更新,删除和插入.
到目前为止,我可以想到三个不同的地方,你可以做历史表工作.
我的主要问题是,在每个层中完成工作的优点,缺点和缺点是什么.
我可以通过使用触发器方式来考虑的一个优点是,无论在数据库之上实现什么程序,都始终保持完整性.
我开始将SQLAlchemy用于一个新项目,我计划在这个项目中实现类似于此静默提议的审计跟踪:
因为我已经拥有了"有趣"对象的完整历史,所以我在考虑允许用户回滚给定版本,让他们有可能无限制undo.
这可以用SQLAlchemy以干净的方式完成吗？
在内部API(业务逻辑和ORM)中公开此功能的正确方法是什么？
我是一路走来的路user.rollback(ver=42).
audit ×3
database ×2
audit-trail ×1
crud ×1
history ×1
logging ×1
postgresql ×1
python ×1
rollback ×1
sql-server ×1
sqlalchemy ×1