Полезен ли Oracle AQ / Streams в моей ситуации?

Question

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

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

Answer 1

Есть много причин, по которым система массового обслуживания полезна, но я не уверен, что они применимы в вашей ситуации.Похоже, у вас есть одна система, хранящаяся в одной базе данных.Таким образом, я не думаю, что организация очередей даст какое-либо преимущество перед обычными таблицами.

Ситуации, в которых AQ предоставляет преимущества, включают:- как механизм взаимодействия разных систем (несколько баз данных) друг с другом

• когда у вас слабосвязанные системы - производитель рассылки сообщений неизвестному количеству подписчиков

Я думаю, что для управления состоянием в единой системе, например, как вы описываете, Streams/AQ был бы излишним.

Answer 2

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

В 10g и ниже Oracle реализовала транзакционную операцию удаления из очереди с помощью SKIP LOCKED синтаксис, который конечным пользователям был запрещен.В 11g этот синтаксис был раскрыт, чтобы позволить людям решить эту проблему (покажите мне следующую запись), не требуя реализаций AQ .

Дополнительным преимуществом AQ является то, что очистка очереди является асинхронной.

Большим недостатком AQ является его размер и обслуживание - в конечном итоге создается порядка 7 таблиц / IOT для одной постоянной очереди / темы, и вы не можете напрямую обслуживать эти объекты базы данных, но вы должны выполнять обслуживание через пакеты DBMS_AQ и DBMS_AQADM.

Answer 3

Если ваше приложение действительно имеет такой небольшой объем и предполагается, что задержка в несколько минут приемлема, я бы избегал того и другого и использовал триггеры старой школы для заполнения своих собственных таблиц журналирования.Затем я бы обработал их с помощью заданий pl.И все это для того, чтобы избежать дополнительных функций/сложностей, которые приносит AQ.