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