SQL の循環参照制約は有効ですか?また、それらはどのように解決できますか?

SQL の循環参照制約: 複雑さをナビゲートする

データベース設計では、外部キー制約を通じてテーブル間の関係を確立するのが一般的です。ただし、テーブルがループ内で相互に参照し、循環依存関係が作成される場合、そのようなスキーマは有効ですか?

循環参照の例

2 つのテーブルが含まれる次のスキーマを考えてみましょう。 products と products_picture は、相互に参照します:

CREATE TABLE products (
  ID int(10) unsigned NOT NULL AUTO_INCREMENT,
  DEFAULT_PICTURE_ID int(10) unsigned DEFAULT NULL,
  FOREIGN KEY (DEFAULT_PICTURE_ID) REFERENCES products_pictures (ID) ON DELETE SET NULL ON UPDATE SET NULL
);

CREATE TABLE products_pictures (
  ID int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRODUCT_ID int(10) unsigned NOT NULL,
  FOREIGN KEY (PRODUCT_ID) REFERENCES products (ID) ON DELETE CASCADE
);

このデザインでは、 products.DEFAULT_PICTURE_ID は products_pictures.ID を参照し、products_pictures.PRODUCT_ID は products.ID を参照し、循環参照を作成します。

有効性と影響

専門家の間での一般的なコンセンサスは、循環参照は次のとおりです。データベース スキーマは推奨されません。これらは、挿入や更新などのデータベース操作を実行するときに、複雑さや不整合を引き起こす可能性があります。

オプション 1: Null 許容外部キー列

この問題に対処する 1 つのオプションは、次のとおりです。 2 つの外部キー列が NULL 可能である場合は許可されます。これにより、どのテーブルに最初にデータを挿入するかという「卵が先か鶏が先か」の問題が解決されます。ただし、製品に別の製品に属するデフォルトの画像が含まれる可能性があるため、データの整合性の問題が生じます。

オプション 2: IsDefault 列

別のアプローチは、削除することです。 products から DEFAULT_PICTURE_ID 列を取得し、products_pictures に IsDefault ビット列を追加します。これにより、IsDefault ビットを設定できるピクチャは製品ごとに 1 つだけになります。

オプション 3: 遅延可能な制約

遅延可能な制約を使用すると、特定の制約を後でチェックして適用し、解決することができます。循環参照の問題。このオプションは MySQL ではサポートされていません。

オプション 4: デフォルト ピクチャ用の別のテーブル

循環依存関係を排除し、データの整合性を確保するには、次のような別のテーブルを作成することを検討してください。 product_default_picture として、製品とデフォルトの画像の関係を保存します。このアプローチにより、両方の外部キー列を null 非許容にすることができます。

結論として、循環参照は一部のデータベース システムでは技術的に有効である可能性がありますが、一般的には推奨されません。 MySQL スキーマ内の循環参照に対処し、データの整合性を確保するには、上記のオプションを検討してください。

以上がSQL の循環参照制約は有効ですか?また、それらはどのように解決できますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。