部品テーブルの場合: ALTER TABLE Parts ADD INDEX idx_model ( model); この文は、パーツ テーブルにインデックスを追加することを意味します。インデックスはモデル フィールドに構築され、インデックスの名前は idx_model です。 PC テーブルの場合も同様です:
ALTER。 TABLE pc ADD INDEX idx_cpumodel (cpumodel);
実際には、これら 2 つのインデックスはテーブルの作成時に設定できます。これは、
の必要性を定義するためのものです。 key PC の CPU モデルは部品テーブル内の対応するモデルを参照する必要があるため、2 つのテーブル間に次の「制約」が確立されます。そのため、PC テーブルの cpumodel フィールドを設定します。つまり、このキーの参照値は他のテーブルから取得されます
ALTER TABLE pc ADD CONSTRAINT fk_cpu_model <.> FOREIGN KEY (cpumodel) REFERENCES Parts( model);
最初の行は、pc テーブルの外部キーを設定し、この外部キーに fk_cpu_model という名前を付けます。2 行目は、このテーブルの cpumodel フィールドを外部キーとして設定します。 3 行目は、この外部キーの制約がパーツ テーブルのモデル フィールドからのものであることを示しています。このようにして、PC を作成するときに使用される CPU モデルがパーツ テーブルに存在しません。その後、MySQL はこの PC の作成を禁止します。
カスケード操作
すべてがうまくいきましたね。 次の状況を考えてみましょう: 技術者は、1 か月前に部品表に入力された特定のシリーズの CPU のモデル (モデルは多数ある可能性があります) がすべて間違った文字を入力していることを発見しました。 、今度は修正する必要があります。私たちが望んでいるのは、部品テーブルの参照列が変更されたときに、対応するテーブルの参照列も自動的に修正されることです。
外部キーを定義するときにこのキーワードを最後に追加できます:
ON UPDATE CASCADE; つまり、メイン テーブルが更新されると、サブテーブルがチェーン更新アクション。これを「カスケード」操作と呼ぶ人もいるようです。 :)
このステートメントを完全に記述すると、次のようになります:
ALTER TABLE pc ADD CONSTRAINT fk_cpu_model FOREIGN KEY (cpumodel) REFERENCES Parts(model) ON UPDATE CASCADE;