在Postgres中使用Audit Table为NOTIFY / LISTEN创建触发器是一个好主意吗？

Question

所以我有一个postgres数据库，我已经安装了一个审计表 - 源码https://wiki.postgresql.org/wiki/Audit_trigger_91plus

现在我的问题如下：

我一直想创建一种流，通知我任何有权访问我的数据库的应用程序所做的任何更改。 现在，我知道我可以通过pg创建一个触发器和一个pub / sub，但这将占用性能时间，这可能会随着DB的扩展而变得显着。

因此，我想知道是否要在主表上执行相同的NOTIFY / LISTEN功能，而不是减慢实际的数据库，而是将其安装在审计表上。

有没有人这样做过？ 如果是这样，你有什么经验，专业人士？ 利弊？ 或者，如果有人知道为什么我应该或不应该这样做，请你告诉我。

谢谢

Answer 1

通过NOTIFY/LISTEN ，PRO-s：

与服务器轻松通信，无需拉动数据变化。

通过NOTIFY/LISTEN ，CON-s：

实践表明，仅仅设置并监听事件是不够的，因为由于各种通信问题，频道每次都会发生故障。 对于一个严肃的系统，您需要安装一个额外的监控服务，以验证您的监听器是否仍在运行，如果没有 - 销毁现有监听服务并创建新监听服务。 这可能很棘手，你可能找不到这样做的好例子。

通过预定的数据拉取，PRO-s：

• 简单 - 您只需根据计划检查数据变化;
• 可靠性 - 一旦拉动实施工作，就没有什么可以打破的。

通过预定数据拉取，CON-s：

服务器的额外流量，具体取决于您需要查看数据更改的速度，以及如何干扰（如果有的话）其他对服务器的请求。