我的情況下是否可以使用Oracle AQ / Streams？

Question

我正在編寫一個工作流系統，該工作流系統在每個步驟均由明確的人為交互驅動。 即，將任務分配給一個人，該人從幾個有限的選項中選擇{批准，拒絕，轉發}，然后將其發送給下一個人或終止。

只是想知道Oracle Streams / AQ是否可以在由常規Web應用程序代碼管理的平面表上提供任何功能。 每個動作之后的處理量是相當有限的，並且處理量也不是很高，因此實際上並不需要通過將它們放入隊列來限制它們。 引入隊列結構有什么好處，或者對我的情況來說是過大了？

Answer 1

排隊的最大優勢在於，它可以使並發問題變得非常簡單（否則，該問題實際上很難解決（該記錄只顯示一個線程用於處理））。 如果沒有排隊，則可以嘗試但不能確保這種行為，並且最終必須進行大量中間狀態更新並檢查失敗的線程。

在10g及以下版本中，Oracle使用SKIP LOCKED語法實現了事務出隊操作，不允許最終用戶使用。 在11g中，已經公開了該語法，使人們無需AQ實現即可解決該問題（請向我顯示下一條記錄）。

AQ的第二個優點是隊列清理是異步的。

AQ的最大缺點是它的大小和維護性-一個最終會為單個持久性隊列/主題創建大約7個表/ IOT，而一個人不能直接維護這些數據庫對象，但是您必須通過以下方式進行維護DBMS_AQ和DBMS_AQADM軟件包。

Answer 2

排隊系統有益的原因有很多，但我不確定它們是否適用於您的情況。 聽起來您有一個系統，所有系統都存儲在一個數據庫中。 因此，我認為排隊不會比普通表提供任何優勢。

AQ帶來好處的情況包括：-作為不同系統（多個數據庫）相互對話的機制

• 當您的系統松散耦合時-發送給未知數量訂閱者的消息的產生者

正如您所描述的那樣，作為一種在單個系統中管理狀態的方法，我認為Streams / AQ可能會過大。

Answer 3

如果您的應用程序的容量確實很小，並且可以接受幾分鍾的延遲，那么我將避免兩者都使用，並使用老式的觸發器來填充我自己的日志表。 然后，我將使用pl作業處理這些。 所有這些都避免了AQ帶來的附加功能/復雜性。