首页 文章

更改日志/审计数据库表的最佳设计? [关闭]

提问于
浏览
103

我需要创建一个数据库表来存储不同的更改日志/审核(当添加,删除,修改等内容时) . 我不需要存储特别详细的信息,所以我想的是:

  • id(用于活动)

  • 触发它的用户

  • 事件名称

  • 事件描述

  • 事件的时间戳

我在这里错过了什么吗?显然我可以继续改进设计,虽然我不打算让它变得复杂(为事件类型创建其他表格或类似的东西是不可能的,因为它是我需要的复杂因素) .

9 回答

  • 0

    在我正在研究的项目中,审计日志也是从非常简约的设计开始的,就像你描述的那样:

    event ID
    event date/time
    event type
    user ID
    description
    

    这个想法是一样的:保持简单 .

    然而,很明显这种简约设计还不够 . 典型的审计正在沸腾到这样的问题:

    Who the heck created/updated/deleted a record 
    with ID=X in the table Foo and when?
    

    因此,为了能够快速回答这些问题(使用SQL),我们最终在审计表中增加了两个列

    object type (or table name)
    object ID
    

    那时我们的审计日志设计确实稳定了(现在几年) .

    当然,最后的“改进”仅适用于具有代理键的表 . 但猜猜怎么了?我们所有值得审核的表都有这么一把钥匙!

  • 63

    您可能还需要审核其他一些内容,例如表/列名称,进行更新的计算机/应用程序等等 .

    现在,这取决于您真正需要的详细审核以及在什么级别 .

    我们开始构建自己的基于触发器的审计解决方案,我们希望审计所有内容,并且还有一个恢复选项 . 事实证明这太复杂了,所以我们最终对基于触发器的第三方工具ApexSQL Audit进行逆向工程,以创建我们自己的自定义解决方案 .

    提示:

    • 包括值之前/之后

    • 包括3-4列用于存储主键(如果它是复合键)

    • 如Robert所建议的那样将数据存储在主数据库之外

    • 花费大量时间准备报告 - 特别是那些你可能需要恢复的报告

    • 计划存储主机/应用程序名称 - 这可能对跟踪可疑活动非常有用

  • 22

    我们还记录旧值和新值以及它们来自的列以及要在审计详细信息表中审计的表的主键 . 想一想你需要的审计表是什么?您不仅想知道谁进行了更改以及何时进行更改,而且当发生不良更改时,您需要快速将数据放回原处 .

    在设计时,您应该编写代码来恢复数据 . 当你需要恢复时,通常是匆忙,最好已经做好准备 .

  • 7

    这里和类似的问题有很多有趣的答案 . 我可以从个人经验中添加的唯一内容是:

    • 将审计表放在另一个数据库中 . 理想情况下,您希望与原始数据分离 . 如果需要还原数据库,则不需要还原审计跟踪 .

    • 尽可能合理地反规范化 . 您希望表具有尽可能少的原始数据依赖性 . 审计表应该简单且快速,以便从中检索数据 . 没有花哨的联接或查找其他表来获取数据 .

  • 4

    我们在 table 上有什么: -

    Primary Key
    Event type (e.g. "UPDATED", "APPROVED")
    Description ("Frisbar was added to blong")
    User Id
    User Id of second authoriser
    Amount
    Date/time
    Generic Id
    Table Name
    

    通用id指向已更新的表中的一行,表名是该表的名称作为字符串 . 不是一个好的数据库设计,但非常实用 . 我们所有的表都有一个代理键列,因此效果很好 .

  • 1

    有很多方法可以做到这一点 . 我最喜欢的方式是:

    • mod_user 字段添加到源表(要记录的字段) .

    • 创建一个包含要记录的字段的日志表,以及 log_datetimeseq_num 字段 . seq_num 是主键 .

    • 在源表上构建一个触发器,只要有任何受监视的字段发生更改,就会将当前记录插入到日志表中 .

    现在你已经记录了每一个变化以及是谁做到了 .

  • 4

    通常,自定义审计(创建各种表)是一个糟糕的选择 . 可以禁用数据库/表触发器以跳过某些日志活动 . 自定义审计表可能被篡改 . 例外情况可能会导致申请失效 . 不要提到设计稳健解决方案的困难 . 到目前为止我在这个讨论中看到一个非常简单的案例 . 您需要与当前数据库和任何特权用户(DBA,开发人员)完全分离 . 每个主流RDBMS都提供审计工具,甚至DBA也无法禁用,篡改秘密 . 因此,RDBMS供应商提供的审计功能必须是第一选择 . 其他选项是第三方交易日志阅读器或自定义日志阅读器,它将分解的信息推送到消息系统,最终以某些形式的审计数据仓库或实时事件处理程序结束 . 总结:解决方案架构师/“Hands on Data Architect”需要根据需求参与这样一个系统 . 通常只有交给开发人员解决方案才是非常严肃的事情 .

  • 3

    根据分离原则:

    • 审计数据表需要与主数据库分开 . 由于审计数据库可以包含大量历史数据,因此从内存利用率的角度来看,将它们分开是有意义的 .

    • 不要使用触发器来审计整个数据库,因为最终会有一堆不同的数据库需要支持 . 您将不得不为DB2,SQLServer,Mysql等编写一个 .

  • 19

    迟到了,但我强烈推荐AutoAudit project .
    由SQL MVP Paul Nielsen和John Sigouin撰写的's 100% free and open source. It' . 它非常稳定,目前版本为3.30 .

    安装简单 . 只需运行他们提供的SP即可 . 它将创建一个审计模式,一些维护SP和执行审计所需的触发器 . 从那里,只需选择您想要审核的表格以及详细信息 .

相关问题