ORACLE SQL ПРОЦЕДУРА ЗАПУСКА ИЛИ СОХРАНЕННАЯ ПРОЦЕДУРА НА ДВУХ РАЗНЫХ ТАБЛИЦАХ - PullRequest
0 голосов
/ 16 июня 2020

У меня две таблицы. Я хочу создать триггер для этих двух таблиц. Столбцы в таблицах выглядят так, как показано ниже.

Table_A

CL_ID, TIMESTAMP_A, OUT_ID, STATUS ETC.

Table_B

OUT_ID, TIMESTAMP_B, ETC.

Данные автоматически вставляются в эти две таблицы (из-за интегрированных систем). Мне нужно управлять вот так.

IF TIMESTAMP_A > TIMESTAMP_B THEN 
   UPDATE TABLE_A SET OUT_ID =' ' AND STATUS = 'ABC' 
   WHERE A.OUT_ID = B.OUT_ID

У меня не слишком большой опыт работы с триггером. Я попытался создать представления из этих двух таблиц с помощью «join» и написал «вместо триггера», но это не сработало. Имеет ли для этого смысл хранимая процедура? Может ли кто-нибудь помочь мне в этом вопросе? Заранее спасибо за помощь.

1 Ответ

0 голосов
/ 18 июня 2020

Здесь можно описать множество сценариев ios.

Что определяет TIMESTAMP_A> TIMESTAMP_B? Есть ли какая-нибудь строка в таблице? Я предполагаю, что мы имеем в виду строку в таблице А и строку партнера в таблице В, где «партнер» чем-то определяется. Я предполагаю, что OUT_ID

Таблицы 1 к 1? 1 ко многим? Если второе, то каково правило? Есть отметка времени? Нижайший? Самый высокий?

Даже если мы примем самый простой случай, 1-к-1, теперь у нас есть проблема , когда реализуем это правило.

Если я вставлю в tableA, тогда (в настоящее время) еще нет строки в tableB ... Можем ли мы гарантировать, что будет строка tableB в конечном итоге ? Будет ли это частью той же транзакции? Что произойдет, если мы позже обновим одну из строк таблицы? Выполняем ли мы повторно тот же лог c?

Так что, даже если предположить более простой случай: 1-к-1 и вставлены в одну транзакцию

, тогда все равно сложно, потому что в Oracle, ie нет такой вещи, как «триггер фиксации», вы не можете запустить код, когда кто-то выдает фиксацию. Итак, в конечном итоге вы бы посмотрели на использование чего-то вроде AQ для помещения записи в очередь, которая регистрирует OUT_ID для tableA, и имеет второй фоновый процесс, прослушивающий очередь, который затем будет действовать на сообщение. Поскольку он видит это сообщение только во время фиксации, то к этому этапу tableA и tableB будут иметь нужную вам строку, и фоновый процессор может действовать на это.

Cross-table logi c (в любой базе данных) сложнее, чем кажется.

...