論理的にはであるフィールドでcascade/および同様の制約を使用する必要がない場合、美学以外に、それを明示的に宣言する理由はありますか？restrictforeign keyforeign key
整合性をテストする必要があるため、実際にはパフォーマンスが低下しませんか？
編集：明確にするために、私はそれを必要としない：
cascadeとにかくそれらの値を編集したり削除したりしないので、同様のチェックを行う必要はありませんINSERTする必要もありませんrestrictこの種の制約により、データベースが何らかの理由で破損した場合でも、その関係が引き続き有効であることが保証されることを理解しています。これは良いことです。しかし、私の場合、この関数を使用する他の理由があるのではないかと思います。私は何かが足りないのですか？
この質問に対する答えは、実際にはあなたの質問にも当てはまるかもしれません。
他のテーブルの行を参照する列がテーブルにある場合は、常に外部キーを使用する必要があります。これらのチェックによって提供される機能が「必要ないと思われる」場合でも、データの整合性を保証するのに役立ちます。自分のコードのチェックを忘れました。
リレーショナルデータベースは非常に最適化されたアルゴリズムを使用して実行するため、外部キーチェックのパフォーマンスへの影響はほとんどの場合無視できます（上記のリンクを参照）（結局のところ、エンティティ間の関係を実際に定義するものであるため、これらは重要な機能です）。
FKのもう1つの大きな利点は、他の人がデータベースのレイアウトを理解するのにも役立つことです。
編集： 上記のリンク先の質問はSQL-Serverに関するものなので、MySQLに非常によく似た種類の応答がある質問を次に示します。MySQLに外部キーを導入するとパフォーマンスが低下しますか
あなたはそれをしなければなりません。書き込みでパフォーマンスに影響する場合は、「ピクセル」の問題です。
主なパフォーマンスの問題は読み取り中です-FKは、クエリオプティマイザが最適なプランなどを選択するのに役立ちます。DBMS（-s）（クロスDBMSソリューションを提供する場合）が今それから得られる場合でも、後で発生する可能性があります。
だから答えは-はい、それは麻酔だけではありません。