Oracle - первичный ключ и внешний ключ

Question

Будет ли этот сценарий работать?

Таблица 1

Column1 PK 
Column2 FK 

Таблица 2

Column1 PK 
Column2 FK 

Столбец2 таблицы 2 эталонных COLUMN1 таблицы 1 и COLUMN2 таблицы 1 ссылка COLUMN1 таблицы 2. Будет ли это работать на все? Я думаю, что этого не произойдет.

Answer 1

Это будет, но один из FK должен быть нулевым. Если вы хотите определить отношения 1: 1, почему бы просто не использовать общий первичный ключ? (ПК на одном столе - FK на ПК другой таблицы)

Answer 2

Да, он будет работать с отложенными ограничениями.
Например, можно создать таблицу chicken и таблицу egg, обе таблицы ссылаются друг на друга.
Ограничения будут проверяться в момент фиксации.

Answer 3

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

SQL> insert all 
    2  into t2 values (c2, c1) 
    3  into t1 values (c1, c2) 
    4 select 42 as c1, 23 as c2 from dual 
    5/
insert all 
* 
ERROR at line 1: 
ORA-02291: integrity constraint (APC.T2_FK) violated - parent key not found 


SQL> 

отложенным ограничения предлагают обходной путь.

SQL> alter table t2 drop constraint t2_fk 
    2/

Table altered. 

SQL> alter table t2 add constraint t2_fk foreign key (col_b) 
    2  references t1 (col_1) deferrable initially deferred 
    3/

Table altered. 


SQL> insert all 
    2  into t2 values (c2, c1) 
    3  into t1 values (c1, c2) 
    4 select 42 as c1, 23 as c2 from dual 
    5/

2 rows created. 

SQL> 

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

Однако использование отложенных ограничений всегда является обходным путем; обычно они указывают на сбой в приложении (cough Hibernate cough), но в этом случае проблема будет в модели данных. Что значит сказать T1 является родителем T2 и одновременно T2 является родителем T1? Это вздор.

Кроме того, такая схема обеспечивает связь 1: 1, которая представляет собой другой красный (или, по меньшей мере, янтарный) флаг в модели данных. Даже если есть истинная причина отношения 1: 1, все равно было бы лучше определить одного чистого родителя и одного четкого ребенка.

ТЛ: д-р

Это может быть сделано, но это не должно быть