Разрешение внешнего ключа перед вставкой новых строк

Question

У меня есть необработанная таблица , используемая в качестве буфера, в который периодически вставляются новые данные (в среднем ~ 20 000 строк, вставляемых в объеме каждые ~ 5 минут). Затем существует сохраненная процедура PL / SQL, которая читает эту необработанную таблицу и вставляет информацию в отдельные таблицы базы данных.
К сожалению, я не могу выполнить прямую массовую вставку в мою таблицу назначения из строк, хранящихся в raw table , потому что часть столбцов (10 из 20) являются внешними ключами в таблице назначения. Это означает, что перед выполнением вставки мне нужно разрешить все идентификаторы внешнего ключа, а затем использовать их для вставки новых строк в таблицу назначения.
Кроме того, элемент в таблице внешнего ключа не может быть там, поэтому его необходимо вставить в таблицу внешнего ключа, а затем его идентификатор можно использовать в качестве идентификатора внешнего ключа.

Решением, которое я собираюсь использовать, является наличие хранимой процедуры, которая:
1) для каждого столбца необработанной таблицы , который соответствует внешнему ключу в таблице назначения, я выбираю отдельные значения столбца, и для каждого я выбираю идентификатор в внешней таблице, и если это не так не существует, я вставляю его, возвращая относительный идентификатор;
2) Я записываю в пустую временную таблицу (урезанную каждый раз перед вставкой в ​​нее) те же строки raw table , но с разрешенными внешними ключами;
3) Я делаю массовую вставку в таблицу назначения, выбирая значения из временной таблицы.

Зачем использовать временную таблицу? Потому что я хочу избежать вставки строка за строкой в ​​таблицу назначения, которая содержит более 50 миллионов строк.

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

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

Я попытался обобщить свой сложный рабочий процесс, опуская некоторые детали и немного обобщая контекст.

Answer 1

Какой процент внешних ключей не разрешается?

Вы можете сделать следующее для каждой из этих основных таблиц внешнего ключа

INSERT INTO parent_table (id, name)
SELECT id.nextval, r2.name
FROM (SELECT DISTINCT r.name FROM raw)
WHERE r2.name NOT IN (SELECT name FROM parent_table)

Тогда вы узнаете, что все они существуют, и можете просто вставить.

Или, если в основном они есть, вы можете посмотреть BULK .. ИСКЛЮЧЕНИЯ В и позволить механизму SQL сообщить вам, какие из них не пройдены, и разобраться с ними по отдельности.