django AuditTrail 与还原
我正在开发一个新的网络应用程序，我需要将数据库中的任何更改存储到审核表中。 这种审计表的目的是，稍后在真正的物理审计中，我们可以确定在某种情况下发生了什么，谁编辑了什么以及在例如复杂计算时数据库的状态是什么。 所以大多数审计表将被写入而不是读取。 有时可能会生成报告。
我已经寻找可用的解决方案
- AuditTrail - 简单，这就是我倾向于它的原因，我可以了解它的单文件代码。
- Reversion - 看起来使用起来很简单，但不确定如果需要的话修改它有多容易。
- rcsField 似乎非常复杂，无法满足我的需求，
我还没有尝试过任何人其中，所以我想知道一些真实的经验以及我应该使用哪一个。 例如哪一个速度更快、占用空间更少、易于扩展和维护？
I am working on an new web app I need to store any changes in database to audit table(s). Purpose of such audit tables is that later on in a real physical audit we can asecertain what happened in a situation, who edited what and what was the state of db at the time of e.g. a complex calculation.
So mostly audit table will be written and not read. Report may be generated though sometimes.
I have looked for available solution
- AuditTrail - simple and that is why I am inclining towards it, I can understand it single file code.
- Reversion - looks simple enough to use but not sure how easy it would be to modify it if needed.
- rcsField seems to be very complex and too much for my needs
I haven't tried anyone of these, so I wanted to know some real experiences and which one I should be using. e.g. which one is faster uses less space, easy to extend and maintain?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
就我个人而言，我更喜欢在数据库中创建审核表并通过触发器进行填充，以便存储任何更改，甚至来自查询窗口的临时查询。 我永远不会考虑不基于数据库本身的审计解决方案。 这很重要，因为恶意更改数据库或实施欺诈的人不太可能通过 Web 界面进行操作，而是直接在后端进行。 这种事情更多是由心怀不满或盗窃的员工造成的，而不是外部黑客造成的。 如果您已经在使用 ORM，您的数据将面临风险，因为权限位于表级别，而不是它们所属的 sp 级别。 因此，捕获数据的任何可能的更改而不仅仅是 GUI 中的更改更为重要。 我们有一个动态过程来创建审计表，每当新表添加到数据库时就会运行该审计表。 由于我们的审计表仅填充更改而不是整个记录，因此我们不需要在每次添加字段时都更改它们。
此外，在评估可能的解决方案时，请确保考虑恢复数据以撤消特定更改的难度。 一旦有了审计表，您就会发现这是您需要从中做的最重要的事情之一。 还要考虑当数据库模式发生变化时维护信息的难度。
因为它看起来最容易理解而选择一个解决方案通常不是一个好主意。 在满足要求、安全性等后，这应该是您选择标准的最低标准。
Personally I prefer to create audit tables in the database and populate through triggers so that any change even ad hoc queries from the query window are stored. I would never consider an audit solution that is not based in the database itself. This is important because people who are making malicious changes to the database or committing fraud are not likely to do so through the web interface but on the backend directly. Far more of this stuff happens from disgruntled or larcenous employees than outside hackers. If you are using an ORM already, your data is at risk because the permissions are at the table level rather than the sp level where they belong. Therefore it is even more important that you capture any possible change to the dat not just what was from the GUI. WE have a dynamic proc to create audit tables that is run whenever new tables are added to the database. Since our audit tables populate only the changes and not the whole record, we do not need to change them every time a field is added.
Also when evaluating possible solutions, make sure you consider how hard it will be to revert the data to undo a specific change. Once you have audit tables, you will find that this is one of the most important things you need to do from them. Also consider how hard it will be to maintian the information as the database schema changes.
Choosing a solution because it appears to be the easiest to understand, is not generally a good idea. That should be lowest of your selction criteria after meeting the requirements, security, etc.
我无法向您提供其中任何一个的真实经验，但我想进行观察。
我认为 AuditTrail 是指 Django wiki 上的 AuditTrail。 如果是这样，我想您应该看看由同一作者（Marty Alchin aka @gulopine）在他的书中开发的
HistoricalRecordsPro Django。 它应该与 Django 1.x 配合得更好。这是我将在即将进行的项目中使用的方法，并不是因为它从技术角度必然击败其他方法，而是因为它符合该应用程序审计跟踪的“现实世界”期望。
I can't give you real experience with any of them but would like to make an observation.
I assume by AuditTrail you mean AuditTrail on the Django wiki. If so, I think you'll want to instead look at
HistoricalRecordsdeveloped by the same author (Marty Alchin aka @gulopine) in his book Pro Django. It should work better with Django 1.x.This is the approach I'll be using on an upcoming project, not because it necessarily beats the others from a technical standpoint, but because it matches the "real world" expectations of the audit trail for that application.
正如我在问题中所说， rcField 似乎满足了我的需求，这很简单，我想存储对表的任何更改，并且可能稍后会返回这些更改以生成一些报告。
所以我测试了 AuditTrail 和 Reversion
Reversion 似乎是一个更好的完整应用程序，具有许多功能（我不需要），而且据我所知，它以 XML 或 YAML 格式将数据保存在单个表中，我认为这
AuditTrail 在这方面胜出，它为每个表生成一个相应的审计表，因此可以轻松跟踪更改，每个表数据较少，并且可以轻松操作和用户生成报告。
所以我将使用 AuditTrail。
As i stated in my question rcField seems to be to much for my needs, which is simple that i want store any changes to my table, and may be come back later to those changes to generate some reports.
So I tested AuditTrail and Reversion
Reversion seems to be a better full blown application with many features(which i do not need), Also as far as i know it saves data in a single table in XML or YAML format, which i think
AuditTrail wins in that regard that for each table it generates a corresponding audit table and hence changes can be tracked easily, per table data is less and can be easily manipulated and user for report generation.
So i am going with AuditTrail.