-1

我想为我们的系统添加审计跟踪，所以当任何添加/删除/更新操作发生时，我会记录它，并提供以下信息：-

  1. CRUD 操作类型。是添加、删除还是更新。

  2. 被修改的记录ID。

  3. 日期和时间。

现在我找到了两种可以遵循的方法；要么有一个包含以下字段的审计跟踪表：-

  • ID .如 123445。
  • CRUD_描述。比如删除
  • 记录_ID。如Qaeop12771
  • 日期。如 1june2O13

或者有两个表，一个用于 CRUD 操作的查找表，例如

  • CRUD_ID。比如3。
  • CRUD_Description.如删除。

然后审核试用会参考上表：-

  • ID。如 123445。
  • CRUD_ID（这将是 CRUD 表的外键），例如 3。
  • 记录_ID。如Qaeop12771
  • 日期。如 1june2O13

那么哪种方法更好？

第二个问题如果我会遵循第二种方法。那么是否更喜欢在我的代码中使用 CRUD_ID，例如，如果 oprration 是删除，我可能会让我的代码看起来像：-

Inset into audit_trail (ID, CRUD_ID, Record_ID, Date) values ( 123445, 3,12771,1june2O13) //CRUID 3 represents delete operation.

此致

4

2 回答 2

15

Trail_History从数据库设计的角度来看（忽略数据库功能和应用程序架构），我更喜欢通过实现一个对任何表都没有外键调用的平面表，为每个实体和每个字段创建一个用于审计跟踪（更改历史记录）的表，列将是：

  1. UserCode：应用程序用户唯一标识符，表示谁进行了更改。（强制的）
  2. TransactionCode：任何 CRUD 操作都需要有唯一的事务代码（如 GUID）（强制）
  3. ChangeDate： 交易日期。（强制的）
  4. EntityName: 被操作的实体（表）。（强制）
  5. ObjectId: 被操作主键的实体。
  6. FieldName：实体字段名称。
  7. OldValue：实体字段旧值。
  8. NewValue: 实体字段新值
  9. OperationType: CRUD 操作鉴别器。（强制的）

采用这种方法
可以跟踪任何实体（表）
报告将是可读的
仅记录更改。
事务代码将是通过单个操作检测更改的关键点，将回答第二个问题。

希望有所帮助。

于 2013-06-01T09:35:32.053 回答
0

实际上，这两种方法几乎相同。

第二个会稍微更有效，但灵活性较差，因为如果您需要新的审计操作，则需要在类型表中插入新记录。

您需要审核多少信息的问题更有趣。因为假设三个用户在彼此之后更新了记录，您仍然不知道谁更改了您的设计中的哪些内容。

于 2013-06-01T09:49:36.713 回答