Один из способов справиться с этим - создать материализованное представление главной таблицы в локальной базе данных, а затем создать ограничение целостности, указывающее на MV.
Это работает. Но это может привести к некоторым проблемам. Во-первых, если вам когда-либо понадобится полностью обновить материализованное представление, вам нужно отключить ограничение перед выполнением do. В противном случае Oracle не сможет удалить строки в MV до ввода новых строк.
Во-вторых, вы можете столкнуться с некоторыми временными задержками. Например, допустим, вы добавили запись в основную таблицу на удаленном сайте. Затем вы хотите добавить дочернюю запись в локальную таблицу. Но MV настроен на ежедневное обновление, а это еще не произошло. Вы получите нарушение внешнего ключа просто потому, что MV не обновился.
Если вы идете по этому пути, ваш самый безопасный подход - настроить MV на быстрое обновление при фиксации мастер-таблицы. Это будет означать, что ссылка на БД будет открыта почти все время. И вам придется работать администратором, если вам когда-нибудь понадобится выполнить полное обновление.
В целом, мы обнаружили, что триггер проще. В некоторых случаях мы просто определили FK в нашей логической модели, но внедрили ее вручную, настроив ежедневную работу, которая будет проверять нарушения и оповещать персонал. Конечно, мы очень осторожны, поэтому эти предупреждения чрезвычайно редки.