基于数据库插入/更新来合并和引发事件？
我们有一个不幸的情况，我们的许多应用程序直接与数据库对话（主要是本机应用程序，我们的托管应用程序通过 DAL）。我们有 300 多个表，需要根据对某些表的修改来引发事件。这些事件将通过企业服务总线 (nServiceBus) 或 MSMQ 引发，我们的应用程序将挂钩这些事件。
例如：
- 如果表 1 中有插入，表 2 中有更新，则引发 Some 事件。
- 如果表 1 中有更新，表 2 中有删除，表 3 中有更新，则引发某些事件。
总体而言，我们预计赛事不会超过 25 场，并且每场赛事最多不会涉及超过 5 张牌桌。
信息：
- 我们执行许多长时间运行的任务，我们的应用程序需要轮询才能完成。
- 我们混合了一些非常旧的应用程序，这些应用程序直接与数据库通信，并且无法将它们更改为使用某种 DAL。
- 我们需要进行一些原始事件过滤，以便仅审核某些事件而不引发某些事件。
- 我们正在使用 SQL Server 2008 R，但我们的所有安装站点可能都没有企业许可证。
我们正在寻找类似 CDC 的解决方案，我们可以将其纳入其中。指向可能的解决方案或输入/经验的指针将非常有帮助:)
We have an unfortunate case where a lot of our applications talk directly to the database (native applications mostly, our managed applications go through a DAL). We have 300 + tables and need to raise events based on modifications to certain tables. These events will be raised via an Enterprise Service Bus (nServiceBus) or MSMQ and our applications will hook onto these events.
For example:
- If there is an insert in table 1 and an update in table 2, raise Some events.
- If there is an update in table 1, a delete in table 2 and an update in table 3, raise Some events.
In all we expect there will not be more than 25 events and each events will not touch more than 5 tables at most.
Info:
- We do a lot of long running tasks and our applications need poll for completion.
- We have a mix of really old applications which talk directly with the database and changing them to use some sort of a DAL is not an option.
- We will need to do some primitive event filtering such that some events are only audited and not raised.
- We are using SQL Server 2008 R, but may not have enterprise licenses at all our installation sites.
We are looking for a CDC like solution which we can hook into. Pointers to possible solutions or input/experiences would be very helpful :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我宁愿避免这种情况，并且已经避免了几次。
我的备份计划（即制定了一个草图但从未实施）是：
使用队列和 Service Broker 意味着触发器不需要任何重要的处理并阻止客户端。
I prefer to avoid this, and have avoided it a couple of times.
My backup plan (ie. worked out a sketch but never implemented) was:
Using a queue and Service Broker means the that the triggers don't need to any significant processing and hold up clients.