- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
CREATE FUNCTION get_date RETURN DATE
IS
BEGIN
RETURN SYSDATE;
END;
DECLARE
v_date DATE;
v_dummy VARCHAR2(2);
BEGIN
v_date := SYSDATE+4/24/60/60;
SELECT MAX(dummy)
INTO v_dummy
FROM dual
connect BY v_date > get_date;
END;
Аще жесть какая-то.
хуле, в норме вещей
когда 1-2-5-10 записей апдейтится - норм. когда 100тыс - файрвол срабатывает.
Если 100к изменений, то их явно должно писать некое приложение. Раз так, то ему не западло кидать эти сообщения в шину/message queue, где все желающие нормально отреагируют. Ынтерпрайзных и не очень шин до жопы, зачем udp из триггера.
в оракле advanced queueing был еще c девятки, а в 12 даже jms из коробки добавили
но все равно, это дело прикладухи, а не базы
Эм, где? Мне всегда казалось, что эту фичу по образу ораклов и прочих Дорогих и Ынтырпрайзных СУБД и пилили.
> это дело прикладухи, а не базы
А вот тут я соглашусь: прикладуха может кинуть нормальное уведомление, имеющее прикладной смысл, а триггер - только унылое "запись с номером 5 в таблице users поменялась".
В том же оракле удобный крон, не спорю, next run datetime можно даже юзер функцией вычислять, но прикрываться отсутствием ssh - бе.