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