Является ли Oracle AQ / Streams каким-либо использованием в моей ситуации?

Question

Я пишу систему документооборота, которая на каждом этапе полностью управляется явным человеческим взаимодействием. То есть задача назначается человеку, который выбирает из нескольких ограниченных вариантов {одобрить, отклонить, переслать}, а затем он либо отправляется следующему человеку, либо прекращается.

Просто любопытно, есть ли у Oracle Streams / AQ что-нибудь, что можно предложить поверх плоских таблиц, управляемых обычным кодом веб-приложения. Объем обработки после каждого действия довольно ограничен, а объем не слишком велик, поэтому нет нужды задушивать объекты, бросая их в очередь. В чем заключаются некоторые преимущества введения структуры очереди или она избыточна для моей ситуации?

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.