我开发了一个.NET Winforms报表查看器（它只是运行查询和显示结果）。实时异常处理，SQL-Server驱动系统
这适用于报告数据库。但是，以上是大型应用程序的一小部分，它从另一个数据库获取数据。它看起来像这样：
受监视的系统状态发生变化（例如延迟增加）=>事件作为事务记录到SQL Server数据库（调用此数据库A）=>这触发了写入相同事件的触发器进入报告数据库。
我不确定两个数据库之间的差异，他们可能会针对不同的目标进行调整，或者可能存在一些财务或甚至是两个数据库的政治原因。
无论如何，该术语提到报表数据库在主数据库上是“事务相关的”。这到底是什么意思？报告数据库完全依赖于数据库A的事务？这让我想到了一些问题：
1）我该如何处理报表数据库没有磁盘空间的情况，但数据库A仍在触发报表数据库的触发器？排队 2）链接到上面，如果我排队触发器和他们的数据不能触发报告数据库（不知道如何，但概念上......），它会工作吗？即使如此，这使得系统不是实时的。
像这样的设置中的异常处理是否还有其他危险/问题？
谢谢
这样的依赖关系实际上在生产中非常糟糕。曾经，触发器和更新（远程）数据库肯定会影响性能。但更重要的是可用性问题。依赖于数据库A的应用程序现在与数据库B的可用性绑定在一起，因为如果数据库B不可用，那么触发器将无法执行其工作，它将失败并且应用程序将遇到错误。因此，现在数据库B的amdinsitrator（s）挂钩了应用程序使用数据库A的操作。
此问题有很多方法，最简单的方法是从数据库A中的发布部署事务复制在数据库B中进行预订。这样就从事务处理的角度分离了两个数据库，从而允许依赖于数据库A的应用程序在数据库B不可用时不加限制地进行，或者只是缓慢地进行。
如果系统必须是实时的，那么触发器是唯一的方法。请注意，触发器是完全同步的 - 报告数据库上的操作必须成功完成，否则触发器将失败，并且很可能在事务数据库上操作失败，因为它处于触发器中，原始表上的语句将失败，可能会或可能不会被捕获，但无论如何，不会发生对事务数据库中该表的更改。
此场景有合理的原因，但它确实在报告数据库上创建了事务数据库的依赖关系，因为如果报告数据库关闭，事务数据库将变为只读或更糟。
这不是你想要的。
如果数据库具有相同的结构，则可以查看复制。通常，当我想到一个报告数据库时，我正在考虑一些针对报告进行了优化的不同结构，而不仅仅是出于性能原因而隔离的另一个数据副本（这很好，但这基本上只是将硬件抛向停止报告用户伤害交易用户的问题）。