これは設計上の欠陥だと思うので、これを答えます。
まず、2つのテーブルが真の場合1:1 関係、なぜあなたはただ一つのテーブルを持っていないのですか？
次に、それが真の1:1でない場合 関係ですが、スーパータイプ-サブタイプの問題であるため、この循環外部キーも必要ありません。 table1としましょう Employeeです およびtable2 Customerです 。もちろん、ほとんどの顧客は従業員ではありません（逆もまた同様です）。しかし、顧客が従業員である場合もあります。これは、3つのテーブルで解決できます：
Person
------
id
PRIMARY KEY: id
Employee
--------
personid
lastname
firstname
... other data
PRIMARY KEY: personid
FOREIGN KEY: personid
REFERENCES Person(id)
Customer
--------
personid
creditCardNumber
... other data
PRIMARY KEY: personid
FOREIGN KEY: personid
REFERENCES Person(id)
説明するシナリオでは、2つのテーブルParentがあります およびChild 1:Nを持つ 関係。次に、（定義された計算に基づいて）すべての親に対して最高のパフォーマンスを発揮する子を何らかの方法で保存する必要があります。
これは機能しますか？：
Parent
------
id
PRIMARY KEY: id
Child
-----
id
parentid
... other data
PRIMARY KEY: id
FOREIGN KEY: parentid
REFERENCES Parent(id)
UNIQUE KEY: (id, parentid) --- needed for the FK below
BestChild
---------
parentid
childid
... other data
PRIMARY KEY: parentid
FOREIGN KEY: (childid, parentid)
REFERENCES Child(id, parentid)
このようにして、必要な参照整合性を適用し（すべてのBestChildは子であり、すべての親には1つのBestChildしかありません）、参照に循環パスはありません。最適な子への参照は、Parentではなく、追加のテーブルに保存されます テーブル。
参加すると、すべての親のBestChildを見つけることができます：
Parent
JOIN BestChild
ON Parent.id = BestChild.parentid
JOIN Child
ON BestChild.childid = Child.id
さらに、複数のパフォーマンステスト（さまざまなタイプのテスト、またはさまざまな日付のテスト）に最適な子を保存する場合は、testを追加できます。 フィールドに入力し、主キーを(test, parentid)に変更します ：
BestChild
---------
testid
parentid
childid
... other data
PRIMARY KEY: (testid, parentid)
FOREIGN KEY: (childid, parentid)
REFERENCES Child(id, parentid)
FOREIGN KEY: testid
REFERENCES Test(id)