Oracle AQ/Streams 对我的情况有用吗？
我正在编写一个工作流程系统，该系统的每一步都完全由明确的人机交互驱动。也就是说，将任务分配给一个人，该人从几个有限的选项{批准、拒绝、转发}中进行选择，然后将其发送给下一个人或终止。
只是好奇 Oracle Streams/AQ 是否能够提供比常规 Web 应用程序代码管理的平面表更好的功能。每个操作之后的处理量相当有限，并且数量也不是非常高，因此实际上没有必要通过将它们放入队列来限制它们。引入队列结构有哪些好处，或者对于我的情况来说它是否太过分了？
I'm writing a workflow system that is driven entirely at each step by explicit human interaction. That is, a task is assigned to a person, that person selects from a few limited options {approve, reject, forward}, and then it is either sent along to the next person or terminated.
Just curious if Oracle Streams/AQ has anything to offer over flat tables managed by regular web application code. The amount of processing after each action is fairly limited and the volume is not terribly high, so there's not really a need to throttle things by throwing them into a queue. What are some of the benefits of introducing a queue structure, or is it overkill for my situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
排队的一大优点是它可以使原本非常困难的并发问题（显示一个且仅一个线程处理该记录）变得非常容易。如果没有队列，您可以尝试但不能确保这种行为，并且最终必须进行大量中间状态更新并检查失败的线程。
在 10g 及以下版本中，Oracle 使用最终用户不允许的
SKIP LOCKED语法实现事务出队操作。在 11g 中，该语法已公开，允许人们解决该问题（显示下一条记录）而不需要 AQ实施。
AQ 的第二个优点是队列清理是异步的。
AQ 的一大缺点是它的大小和维护——最终会为单个持久队列/主题创建大约 7 个表/IOT，并且无法直接维护这些数据库对象，但您必须通过DBMS_AQ 和 DBMS_AQADM 包。
The big advantage with queuing is it can make concurrency issues that are otherwise really hard (show one and only one thread this record for processing) really easy. Without queueing, you could try, but not ensure, that kind of behavior, and you'd have to end up doing a lot of intermediate state updating and checking for failed threads.
In 10g and below, Oracle implemented the transactional dequeue operation with the
SKIP LOCKEDsyntax which end users weren't permitted. In 11g, that syntax has been exposed to allow people to solve that problem (show me the next record) without requiring AQimplementations.
A secondary advantage of AQ is that the queue cleanup is asynchronous.
The big disadvantage of AQ is it's size and maintenance -- one ends up creating on the order of 7 tables / IOTs for a single persistent queue/topic, and one can't directly maintain those database objects, but you have to do maintenance through the DBMS_AQ and DBMS_AQADM packages.
排队系统有益的原因有很多，但我不确定它们是否适用于您的情况。听起来您有一个系统，全部存储在一个数据库中。因此，我认为排队不会比普通桌子提供任何优势。
AQ 提供好处的情况包括：
作为不同系统（多个数据库）相互通信的机制
- 发送给未知数量订阅者的消息的生产者作为管理单个系统中状态的一种方式，如您所描述的，我认为 Streams/AQ 太过分了。
There are many reasons a queuing system is beneficial, but I am not sure they apply in your situation. It sounds like you have a single system all stored in a single database. As such, I don't think queuing would provide any advantage over normal tables.
Situations where AQ provides benefits include:
- as a mechanism for different systems (multiple databases) to talk to each other
As a way to manage state in a single system, such as you describe, I think Streams/AQ would be overkill.
如果您的应用程序的容量确实如此之低，并且假设几分钟的延迟是可以接受的，那么我会避免这两种情况，并使用老式触发器来填充我自己的日志记录表。然后我会用 pl jobs 处理这些。所有这些都是为了避免 AQ 带来的额外功能/复杂性。
If your application is really that low volume and assuming a few minutes of latency is acceptable, I'd avoid both and use old school triggers to populate my own logging tables. I would then process these with pl jobs. All to avoid the additional features/complexities AQ brings.