我的要求是为每个对象的每个属性的更改保留完整的审计跟踪的数据模型。对象定义也是流动的：新属性会随着时间的推移出现或消失。此审计跟踪将与原始数据库分开存在，因此基于触发器的审计模型将不起作用。
在关系数据库中，我可以使用一个大型 ATTRIBUTE_HISTORY 表来实现这一点，该表记录每个属性的每个单独更改，并带有适当的时间戳和责任字段。
我的问题：是否有任何较新的存储模型（BigTable、HBase、CouchDB、RDF 存储等）优于 RDBMS？
问问题
2677 次
6 回答
3
如何存储数据的问题取决于将如何使用它以及其他问题。我建议使用你现在理解的简单的东西，测试你是否知道你期望的可能负载。然后在将来根据需要进行改进。
关于您对基于触发器的审计系统的问题，因为听起来您已经准备好在数据库级别完成工作，所以我有一个建议。使用触发器记录对数据库中表的更改，然后在一夜之间（或无论多么频繁地）处理表的内容，并在存储它的任何位置创建审计跟踪，并清空数据库中的表内容。通过这种方式，您可以在数据库级别捕获更改，但仍然可以满足您将实际审计跟踪存储在其他位置的要求。
于 2009-06-22T15:44:45.853 回答
1
我看不出为什么触发器不能引用不同的数据库。但是，如果该数据库不可用，所有更改都将失败，如果审计数据库在另一台服务器上并且连接已关闭，这可能是一个问题。但是我们的审计是通过触发器进行的，我们有一个单独的审计数据库。
于 2009-05-21T21:34:19.967 回答
0
您还可以在应用程序代码中创建日志记录系统。记录对修改数据库并导致成功提交的每个函数的调用。
回答您的问题：不，只需使用 RDBMS。在日志上运行查询会更容易。
于 2009-05-16T15:40:18.980 回答
0
性能将是此类审计跟踪的一个问题。我会选择缓存（非常容错）并在计数达到某个阈值（例如 1000 条记录）时保留缓存内容。理想情况下，这将是批量更新。
我觉得具有持久性选项（如 H2 ）的内存数据库也应该这样做。但我自己没有用过。
于 2009-06-05T08:56:04.533 回答
0
我不认为一个特定的数据库范式可以被认为优于任何其他的审计日志。这与其说是数据模型问题，不如说是日志记录问题，并且可以被认为与数据存储有些正交。
话虽如此，CouchDB 可以配置为从不删除旧版本的文档。通过为每个文档添加时间戳和可能的用户字段，您可以使用该功能自动保存曾经存储在数据库中的所有对象的完整历史记录。这可能是您可以在数据库中获得的最简单的审计日志设置。
至于其他人，我不知道他们可能对此有什么类型的支持。
注意事项：
（您还必须对数据库中的对象遵循永不删除策略，而只需将对象标记为已删除）
（对于 RDBMS，最简单的解决方案可能是一个简单的表，该表将数据库上运行的每个插入、更新或删除语句记录在带有时间戳和用户字段的文本字段中。我在 postgres 数据库上做过一次，它工作得很好保留历史）
于 2009-06-04T03:49:07.840 回答
0
创建一个包含您要审计的表的名称的表（例如：AuditTable）；最小列应该是：TableName (varchar)、RandomValue (float)。在 AuditTable 上添加一个触发器，该触发器将在 RandomValue 更改时触发 - 此触发器的工作是为 AuditTable 中列出的每个表 (TableName) 动态删除重新创建审计触发器。审计触发器（针对每个表）应插入到 AuditRecord 表中，该表捕获：表名、主键 ID、操作类型（INSERT/UPDATE/DELETE）、原始字段值和更新的字段值。如果表结构发生变化，简单更新 AuditTable 中的 RandomValue 将导致重新生成触发器。您将需要编写为给定表自动生成触发器的代码；
于 2009-06-04T18:05:11.547 回答