Laravel 可审计历史表 - SQL 历史或审计包的优缺点？答案

【问题标题】：Laravel Auditable History Tables - Pro & Cons of SQL History or an auditing package?Laravel 可审计历史表 - SQL 历史或审计包的优缺点？
【发布时间】：2019-04-15 10:40:33
【问题描述】：

我的问题是我不知道该怎么做。我正在考虑建立一个类似的数据库结构（source）：

但是，在研究过程中，我发现有像 this 这样的审计包。所以我想知道，有什么优点和缺点？

我的想法是：

SQL 历史：

专业版：
- 具有特定属性的表的特定来源
- DB 查看器上的每一行都易于阅读
缺点：
- 更难实现
类似于 Laravel 审计

专业版：
- 通过 Trait 轻松实现
- 轻松将历史数据导入 Eloquent
缺点：
- 包含所有表的所有可审计更改的单个审计表
- 很难在 DB 查看器上阅读

你会走艰难的路还是只收包裹？

【问题讨论】：

标签： laravel laravel-auditing

【解决方案1】：

我会使用这个包，主要是因为易于使用和配置。

关于你提到的缺点：

包含所有表的所有可审计更改的单个审计表
很难在 DB 查看器上阅读

首先，我不能说这是一件坏事，因为它可以很容易地将用户与跨不同模型所做的所有更改联系起来。

否则，如果您对每个模型都有一个审计表（order_audits、costumer_audits、...），那么您将不得不使用 JOIN 语句来处理简单的事情，例如获取用户在系统上所做的更改总数，例如。

您指出的第二个原因，我假设是因为某些数据被存储为 JSON。如果是这种情况，您始终可以将存储该数据的列类型从 TEXT 转换为 JSON（包含在 documentation 中）。

其中一个好处（在支持它的 RDBMS 上）是您可以在 JSON 类型列上使用 WHERE 语句来应用过滤，并且鉴于 JSON 类型已经存在了一段时间，我敢打赌有数据库查看器可以正确显示数据，而不是一串JSON。

【讨论】：