Добрый день!

есть таблица логов. например так:

и есть две таблицы:
"новая" tbl_new = в нее льем из внешних источников данные.
и
"боевая" tbl_old = в ней находятся данные, которые нужно проверить на предмет изменений и проапдейтить.
структура у данных разная.


как я вижу решение:
1) хранимка, которая после заливки в tbl_new - вызывается внешним скриптом.
2) в хранимке фиксируется ид записи tbl_log , максимальный в логе на данный момент.
3) делается запрос, на подобии:

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

4) обновляем главную таблицу:
(то же, но апдейт, при этом беру записи из лога - вяжу по ид записи таблицы old_tbl.id. беру записи с tbl_log.id которые старше той, которую получил в п.2)
5) повторяю п. 3. с ключем "после обновления".
6) проверяю сколько записей в п.5 = если больше 0 = значит не все записи обновились.
7) соммит

а вот теперь вопрос:
прошу прокомментировать подход. не лучше ли делать лог через триггер?

что должно быть:
лог изменений.
+
изменения.

структура
new_tbl:
-id
-nw_name
-region_id

old_tbl
-id
-nw_name
-nw_ID
-rel_id

rel_tbl:
-id
-nw_rel_id

:non_rel_id = объединяет записи, где new_tbl.region_id не в rel_tbl.nw_rel_id.
группа данных, не подходящих по структуре среди вновь залитых - складируется отдельно.
гарантируется уникальность new_tbl.id

собственно работаю в сторону уменьшения времени. с корректными логами.

мысль в том, что в рамках сессии не должно быть записей другими хранимками - следовательно набор id >запомненого в п.2
должен быть достаточным.
объемы:
в New_tbl = 40к строк. в др варианте 300к строк.
в old_tbl = 30к .. в др варианте 40к строк.
таблица old_tbl - будет постепенно , но бодро "пухнуть" с использоватием данных из new_tbl. задача не инсертить новых данных, а только апдейтить старые, где поле NW_NAME изменилось.

советы и комментарии,
особенно по каким граблям мне придется пройти - жду.
спасибо.