- 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;
byss 10.09.2014 18:37 # 0
gost 10.09.2014 18:41 # +2
DBdev 11.09.2014 11:12 # +1
Аще жесть какая-то.
bormand 10.09.2014 18:41 # +3
defecate-plusplus 10.09.2014 22:09 # +3
хуле, в норме вещей
bliznezz 11.09.2014 11:34 # +1
когда 1-2-5-10 записей апдейтится - норм. когда 100тыс - файрвол срабатывает.
defecate-plusplus 11.09.2014 12:58 # +2
Если 100к изменений, то их явно должно писать некое приложение. Раз так, то ему не западло кидать эти сообщения в шину/message queue, где все желающие нормально отреагируют. Ынтерпрайзных и не очень шин до жопы, зачем udp из триггера.
bormand 11.09.2014 13:07 # 0
defecate-plusplus 11.09.2014 13:22 # 0
в оракле advanced queueing был еще c девятки, а в 12 даже jms из коробки добавили
но все равно, это дело прикладухи, а не базы
bormand 11.09.2014 13:26 # +1
Эм, где? Мне всегда казалось, что эту фичу по образу ораклов и прочих Дорогих и Ынтырпрайзных СУБД и пилили.
> это дело прикладухи, а не базы
А вот тут я соглашусь: прикладуха может кинуть нормальное уведомление, имеющее прикладной смысл, а триггер - только унылое "запись с номером 5 в таблице users поменялась".
inkanus-gray 10.09.2014 22:20 # +2
defecate-plusplus 10.09.2014 23:04 # +1
bormand 11.09.2014 12:39 # 0
defecate-plusplus 11.09.2014 13:07 # +1
В том же оракле удобный крон, не спорю, next run datetime можно даже юзер функцией вычислять, но прикрываться отсутствием ssh - бе.
bormand 11.09.2014 13:13 # 0
bormand 10.09.2014 18:44 # 0
guest 26.09.2014 03:08 # −2
guest 26.09.2014 20:51 # −2
guest 30.09.2014 20:13 # −2