我要求数据从两个外部应用程序传送到我的.NET / SQL Server表/应用程序。在过去，我使用过夜间处理的XML批处理，然后用户通过UI扫描和批准传入的数据。但他们想要实时饲料。
客户团队目前的计划是使用触发器和sp_send_dbmail。该过程将从外部应用程序直接将数据发布到我的临时表（使用ETL）开始。然后在我的触发器中，我将需要检查一些约束（检查例如是否存在传入的ID）。如果约束通过，则所有记录将在我的目标表/ app中插入/更新。如果没有，（比如缺少ID），那么当前架构建议使用sp_send_dbemail发送电子邮件。我测试了触发器，所有组件都可以工作。
我正在跳入项目中游。有没有更好的方法呢？有没有办法可以在不使用触发器的情况下设置实时Feed？如果我可以说服最终用户进行每小时一次的过程，可以使用具有存储过程的作业代理来进行每小时更新，然后为用户执行UI以查找错误输出的记录？
我不想在所有记录良好的原因（性能，缺乏透明度，没有足够的粒度控制，处理批量插入问题等）中使用触发器。收到多封错误的电子邮件可能会让最终用户感到混乱。
谢谢！
答案 0 :(得分：1)
触发器听起来像是满足您流程的实时要求。如果需要实时，您基本上有两种方法：
就个人而言，我更喜欢第二种方法，但这取决于数据的输入方式。如果一次只有一条记录，那么存储过程是合理的，可以捕获相关字段，进行检查，然后再进行检查。随后插入最终或临时表。如果多批记录分批过来，则难以实施。
我更喜欢存储过程的原因是因为它们更通用。他们不会不必持有锁，同时还要编写审计记录和验证数据。它们更灵活，因为它们允许动态SQL和触发器中不允许的其他构造。我也发现逻辑更容易理解。此外，如果服务器繁忙，可能会延迟对存储过程的调用。一旦调用了触发器，您就处于事务中。
但是，如果设计合理且已经半实现，那么在中间切换方法可能不是一个好主意。也许使用触发器来验证数据然后每5,10或60分钟运行一次的工作的想法将满足用户的要求。如果服务器上的工作负载是一个问题，那么批量处理（即使用预定作业）可能比仅触发方法更合适。