为什么我们需要数据库表中的审核列？

Question

我看到有关于所有表以下审计列许多数据库设计...

• 创建
• 创建日期时间
• 更新通过
• Upldated日期时间

从一个透视我从下面的视角看表格...

个
• 实体表：
  • 审计列很好的候选人）
• 参考表：
  • 审计列可能会或可能不是必需的。在某些情况下，最后的更新信息，根本不需要，因为记录是永远不会被修改。）
• 参考数据表
  • 像国名，实体状态等等......可以不要求审计列因为这些信息仅在系统安装期间创建，并且永远不会改变。

我见过很多设计师一味地把所有审计列所有表，就是这种做法很好，如果是的话可能是什么原因？

我只是想知道，因为我这似乎不合逻辑。我很难弄清楚他们为什么要这样设计他们的数据库？我并不是说他们错了或对，只是想知道为什么？

你也可以给我建议，如果有另一种审计拍打或可用的解决方案......

感谢和问候

Answer 1

许多应用程序使用的是一些在通常不存在像类OOP语言开发业务对象包含什么是通常有用的信息，如这样的审计字段。并不是所有的子类实体都可能需要它，但是如果他们这样做的话，它就在那里。由于数据库的开销很小，并且客户可能会根据审计字段请求另一个奇数统计，所以最好让他们到处都是，而不是根本没有他们。如果东西代表一个静态的信息列表，例如国名，我通常不会把它放在数据库中 - 枚举数据类型是为了这种目的而创建的。

Answer 2

数据审计是许多业务系统所需的内部控制（出于某些原因，请参阅Sarbanes Oxley）。它必须在数据库级别，以确保所有更改都被捕获，尤其是未授权的。

即使使用查找表，一个未经授权的更改可能会在您的系统中产生havok，因此了解是谁进行了更改以及何时进行更改非常重要。什么时候是特别重要的，因为它可以帮助dbas知道在多久之后才能获得备份，以便意外或恶意更改信息。

我们喜欢认为我们所有的员工都值得信赖，但是许多盗用个人数据和恶意破坏公司数据的内容来自内部来源（这就是为什么有许多心存不满的员工是危险的）所有的欺诈行为。但大多数程序员似乎认为他们只需要防范外部威胁。

当然，你仍然会有一些人可以做出未经授权的更改，但是你不能阻止系统管理员这样做。但通过审计，至少可以限制数据损坏的可能性（并且在雇用dbas时并且在数据库服务器上不允许其他人拥有管理员权限时特别小心）。

Answer 3

这些列是为了DBA和数据库开发人员的利益。他们只是提供一个快速机制来回答诸如“这个记录最后一次变化的时间？” “谁改变了它？”它们不够健壮或不够细致，不足以满足SOX，HIPAA或任何其他要求。

在每张桌子上放置这些列就简单多了。所有数据都可以更改，因此了解更改何时发生很有用，特别是如果数据不应该更改。通过使用数据字典生成脚本，可以自动完成添加它们的过程。

通过触发器或某些类似的机制，这些列独立于应用程序进行填充是一种很好的做法。这些列是元数据，应用程序不应该真正意识到它们。

依靠全面的审计跟踪来提供此功能通常不是一种选择。为达标目的收集的审计数据通常具有受限的访问权限，实际上可能存储在单独的物理位置。

Answer 4

我碰巧碰到了这个帖子，因为今天早上我脑海中出现了同样的问题。每个答案都有重要意义，我绝对同意你们所有人的观点。保护业务数据和交易数据无可否认。相反，作者对某些配置或静态数据的审计字段感到怀疑。

这种配置数据不能由用户更新。通常它们也可以放在其他地方，比如属性，配置文件甚至是硬编码的常量。当然，将配置数据放在这些地方可能是不好的设计或风格，但从审计的角度来看，它们是否重要？另外，如果这些数据可以由用户更新，那么唯一可以更新的数据是dba或黑客。真正的恶意dba或黑客在破坏法律之前就已经知道了法律，他们确实找到了规避法律的方法。

对我来说，这个问题与你公司的环境更相关。贵公司是否有跟踪每一点微小信息的文化？贵公司是否经常执行严格的纪律，监督或审计？拥有这些非用户数据的审计字段只是为了满足他们的需求，而不是其他任何目的。