Как реализовать ограничение внешнего ключа кросс-базы данных?

Предположим, у меня есть две схемы: HR и Приказы.Как реализовать ограничение внешнего ключа кросс-базы данных?

[HR].Employees   [Orders].Entries 
--------------   ---------------- 
Id_Employee ----> Employee 
Fullname    Id_Entry 
Birthday    Description 
         Amount

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

-- From [Orders] 
ALTER TABLE Entries 
    ADD CONSTRAINT FK_Entries_Employees FOREIGN KEY (Employee) 
    REFERENCES [email protected]; 
COMMIT; 

ORA-02021: DDL operations are not allowed on a remote database

Есть ли способ обойти это? Это устаревшая база данных, поэтому я не могу изменить существующую схему.

Для NHibernate Толпа: Я использовал бы это отношение для сопоставления объектов домена NHibernate.

источник

2010-09-07 rebelliard

Одним из вариантов было бы создание материализованного представления сотрудников в [Заказы], а затем использование этого в качестве родителя для внешнего ключа.

Конечно, это имеет некоторые недостатки. В частности,

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

- ключи, введенные в СОТРУДНИКИ, не будут доступны для ВХОДОВ, пока не будет обновлено материализованное представление. Если это важно, вы можете настроить его на обновление при фиксации.

Другие альтернативы - это управлять самим принудительным выполнением себя через триггер или через процесс очистки почты. Или убедите DBA в том, что эти схемы могут находиться в одном экземпляре базы данных.

источник

2010-09-07 12:55:03

Спасибо. Раньше я даже не использовал материализованное представление. Как говорится, как бы вы отключили ограничение на фиксацию, чтобы обновить материализованное представление? Опять же, спасибо. – rebelliard

Другая проблема заключается в том, что вам необходимо выполнить восстановление базы данных в определенный момент времени. Это может привести к сбою баз данных. –

С любым материализованным представлением такого рода вы делаете запрос к главной таблице с использованием ссылки БД. Если вы все сделаете правильно, вы можете заставить MV сделать «быстрое» обновление, то есть просто вставить/обновить/удалить строки в MV, которые были изменены в главном. Для этого у вас должен быть первичный ключ в главной таблице. Затем вам нужно создать материализованный журнал представлений для главной таблицы на основе этого ПК. И создайте материализованное представление как «быстро обновить с использованием первичного ключа», чтобы он просто обрабатывал инкрементные изменения. Затем вы можете установить обновление, которое должно быть выполнено по расписанию или ON COMMIT. –

Насколько я знаю, ограничения и ссылочная целостность поддерживаются только в одной базе данных.

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

источник

2010-09-07 12:49:17

Oracle поддерживает перекрестные схемы внешних ключей http://www.akadia.com/services/ora_references_constraint.html – blank

Как реализовать ограничение внешнего ключа кросс-базы данных?

ответ

Смежные вопросы