审计日志数据库设计

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (59)

每次我需要设计一个新的数据库时,我都会花相当长的时间思考如何设置数据库模式,以保存更改的审计日志。

这里已经提出了一些关于这方面的问题,但我不同意对于所有场景都有一种最佳的方法:

修订数据库设计

变更审核数据库表的最佳设计

关于审计跟踪数据库设计的几点思考

我也偶然发现关于维护数据库更改日志的有趣文章它试图列出每种方法的利弊。它写得很好,有有趣的信息,但它使我的决定更加困难。

我的问题是:是否有我可以使用的引用,也许是一本书,或者类似决策树之类的东西,我可以参考这些引用来根据一些输入变量来决定我该走哪一条路,比如:

  • 数据库模式的成熟度
  • 如何查询日志
  • 需要重新创建记录的概率。
  • 更重要的是:写或读性能
  • 记录的值的性质(字符串、数字、BLOB)
  • 可用存储空

提问于
用户回答回答于

几个wiki平台使用的一种方法是分离标识数据和正在审核的内容。它增加了复杂性,但最终得到的是完整记录的审计跟踪,而不仅仅是列出了经过编辑的字段,然后必须将这些字段混在一起,以便让用户了解旧记录的外观。

例如,如果有一个名为机会要跟踪销售交易,实际上需要创建两个单独的表:

机会表中将包含用于唯一标识记录的信息,并包含要引用的用于外键关系的主键。机会_含量表将保存用户可以更改的所有字段,并且希望对这些字段进行审计跟踪。每条记录含量表将包括它自己的PK和修改过的日期数据。机会该表将包括对当前版本的引用,以及关于主记录最初创建的时间以及由谁创建的信息。

下面是一个简单的例子:

CREATE TABLE dbo.Page(  
    ID int PRIMARY KEY,  
    Name nvarchar(200) NOT NULL,  
    CreatedByName nvarchar(100) NOT NULL, 
    CurrentRevision int NOT NULL, 
    CreatedDateTime datetime NOT NULL

以及内容:

CREATE TABLE dbo.PageContent(
    PageID int NOT NULL,
    Revision int NOT NULL,
    Title nvarchar(200) NOT NULL,
    User nvarchar(100) NOT NULL,
    LastModified datetime NOT NULL,
    Comment nvarchar(300) NULL,
    Content nvarchar(max) NOT NULL,
    Description nvarchar(200) NULL

我可能会将内容表的PK作为来自PageID和修订的多列键,前提是修订是身份类型。将使用修订列作为FK。然后,通过这样的加入,可以删除合并记录:

SELECT * FROM Page
JOIN PageContent ON CurrentRevision = Revision AND ID = PageID
用户回答回答于

如果使用的是SQLServer 2008,则可能应该考虑更改数据捕获。

扫码关注云+社区