Oracle AQ/Streams 在我的情况下有用吗？答案

【问题标题】：Is Oracle AQ/Streams of any use in my situation?Oracle AQ/Streams 在我的情况下有用吗？
【发布时间】：2011-01-27 21:04:39
【问题描述】：

我正在编写一个工作流系统，该系统在每一步都完全由明确的人工交互驱动。也就是说，将一项任务分配给一个人，该人从几个有限的选项中进行选择{批准、拒绝、转发}，然后将其发送给下一个人或终止。

只是好奇 Oracle Streams/AQ 是否可以提供任何东西，而不是由常规 Web 应用程序代码管理的平面表。每个动作之后的处理量是相当有限的，而且处理量也不是很高，所以实际上不需要通过将它们放入队列来限制它们。引入队列结构有哪些好处，或者对我的情况来说它是不是有点矫枉过正？

【问题讨论】：

这是我第一次对两个相反的答案投了赞成票（David Sykes + Adam Musch）。恕我直言，两者都有好处。归根结底，这是一个您必须做出决定的设计决策。
是的，我使用 Streams AQ 的次数不如 9i/10g 时代的 AQ。它肯定需要对开发方法的承诺，并且鉴于 11g 中的 SKIP LOCKED 子句，非分布式/SOA 系统的完整 AQ 实现可能是矫枉过正。

【解决方案1】：

队列的最大优势在于它可以使原本非常困难的并发问题（显示一个且仅一个线程处理此记录）变得非常容易。如果没有排队，您可以尝试但不能确保这种行为，最终您必须进行大量中间状态更新并检查失败的线程。

在 10g 及更低版本中，Oracle 使用不允许最终用户的 SKIP LOCKED 语法实现了事务出队操作。在 11g 中，该语法已被公开以允许人们在不需要 AQ 的情况下解决该问题（显示下一条记录）实现。

AQ 的第二个优点是队列清理是异步的。

AQ 的最大缺点是它的大小和维护——一个最终会为单个持久队列/主题创建大约 7 个表/IOT，并且不能直接维护这些数据库对象，但你必须通过 DBMS_AQ 和 DBMS_AQADM 包进行维护。

【讨论】：

【解决方案2】：

排队系统有益的原因有很多，但我不确定它们是否适用于您的情况。听起来您有一个系统，所有系统都存储在一个数据库中。因此，我认为排队不会比普通桌子提供任何优势。

AQ 提供好处的情况包括： - 作为不同系统（多个数据库）相互交流的机制

作为一种在单个系统中管理状态的方法，如您所描述的，我认为 Streams/AQ 会有点矫枉过正。

【讨论】：

【解决方案3】：

如果您的应用程序的容量真的很小并且假设几分钟的延迟是可以接受的，我会避免两者并使用老式触发器来填充我自己的日志记录表。然后我会用 pl 作业处理这些。一切都是为了避免 AQ 带来的额外功能/复杂性。

【讨论】：