我需要一些关于以下场景的建议。
我有多个支持PostgreSQL数据库的嵌入式系统在不同的地方运行，我们在我们的工厂运行CentOS服务器。
每个系统都在远程位置运行，并且在其数据库中有多个表。这些表与服务器的表名具有相同的名称，但每个系统的表名都与其他系统不同，例如：
系统1有表：
sys1_table1sys1_table2系统2有表格
sys2_table1sys2_table2我想在系统1和系统2上完成的每个插入服务器上更新服务器上的表qazxsw poi，qazxsw poi，qazxsw poi和qazxsw poi。
一种解决方案是在每个表上写一个触发器，它将在两个系统表的每个插入上运行，并在服务器表上插入相同的数据。在将数据插入服务器后，此触发器还将删除系统中的记录。此解决方案的问题在于，如果由于网络问题而未建立与服务器的连接，则该触发器将不会执行，否则将浪费插入。我已经为这个sys1_table1检查了以下解决方案
第二种解决方案是将表从系统1和系统2复制到服务器的表。复制的问题是，如果我们从系统中删除数据，它也会删除服务器上的记录。我可以在服务器的表上添加替代触发器，它将在重复的表上更新，因此复制的表可以变空并且它不会影响数据，但是如果我们有超过200个系统，它将生成一个长表列表。
第三种解决方案是使用postgres_fdw或dblink编写外部表并更新服务器表中的数据，但是当我们删除系统表中的数据时，这会影响服务器内的数据，对吗？如果没有与服务器连接会发生什么？
第四个解决方案是在每个系统内部的python中编写一个应用程序，它将连接到服务器的数据库并实时写入数据，如果没有连接到服务器，那么它将把数据存储在sys1_table2或sys2_table1或其他任何内容中。数据所属的表，重新连接后，代码将表数据发送到服务器的表中。
根据这种情况，哪种选择最好？我最喜欢触发解决方案，但有没有办法避免在服务器断开连接的情况下丢失数据？
我会选择第四个解决方案，或者第三个解决方案，只要它是从数据库外部触发的。这样你就可以很容易地避免连接丢失。
带触发器的第一个解决方案存在您已检测到的问题。在数据库事务中启动可能很长的操作（例如跨质量不确定的网络的数据复制）也是一个坏主意。长事务意味着长锁和低效的autovacuum。
如果你有一个支持sys2_table2的最新PostgreSQL版本，第二个解决方案实际上也可能是一个选项。你可以使用Trigger to insert rows in remote database after deletion sys1.table1，这样就不会复制sys2.table2和logical replication。复制可以很好地处理丢失的连接（一段时间），但如果您希望在复制后删除源中的数据，则不能选择复制。