Oracle AQ/Streams 对我的情况有用吗？

题

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

只是好奇 Oracle Streams/AQ 是否能够提供比常规 Web 应用程序代码管理的平面表更好的功能。每个操作之后的处理量相当有限，并且数量也不是非常高，因此实际上没有必要通过将它们放入队列来限制它们。引入队列结构有哪些好处，或者对于我的情况来说它是否太过分了？

解决方案

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

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

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

其他提示

有排队的最大优点是它可以使那些否则真的很难（显示一个且只有一个线程这个记录处理）很容易并发问题。不用排队，你可以尝试，但不能保证，这种行为，你不得不最终做了很多中间状态更新和检查不合格的螺纹。

在10g和下面，甲骨文实现与最终用户是不允许的SKIP LOCKED语法事务出队操作。在11g中，这句法已经暴露，让人们来解决这个问题（显示我的下一个记录），而无需AQ 的实施方式。

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

AQ的一大缺点是它的大小和维护 - 一个最终建立的7桌/ IOT中的一个单一的持久队列/主题的顺序，和一个不能直接维护这些数据库对象，但你必须通过DBMS_AQ和DBMS_AQADM软件包做维护。

如果您的应用程序确实是低量，并假设延迟几分钟是可以接受的，我会避免两者并用的老同学触发器来填充我自己的记录表。然后我会用PL的工作处理这些。所有以避免附加的特征/复杂性带来AQ

许可以下： CC-BY-SA 和归因