私は、MySQL Workbenchを使用してデータベーススキーマを設計しています。これは、ダイアグラムを実行して、それらを変換できるので、かなりクールです。
とにかく、外部キーをサポートしているため、InnoDBを使用することにしました。ただし、外部キーの[更新時]オプションと[削除時]オプションを設定できることに気づきました。誰かが、「制限」、「カスケード」、およびnullの設定を簡単な例で使用できる場所を説明できますか？
たとえば、userを含むテーブルがあるとしますuserID。そして、私messageは2つの外部キー（テーブルuserID内の同じ主キーを参照する）を持つ多対多のメッセージテーブルがあるとしuserます。この場合、[更新時]および[削除時]オプションの設定は役に立ちますか？もしそうなら、私はどちらを選びますか？これが良い例ではない場合、これらがどのように役立つかを説明する良い例を考え出していただけませんか？
ありがとう
回答:
データベースに制約を加えることをためらわないでください。一貫性のあるデータベースが確実に得られます。これがデータベースを使用する理由の1つです。特に、複数のアプリケーションがそれを要求している場合（または1つのアプリケーションのみで、ダイレクトモードと異なるソースを使用するバッチモードの場合）。
MySQLでは、postgreSQLのように高度な制約はありませんが、少なくとも外部キー制約はかなり高度です。
例として、これらの会社のユーザーを含むユーザーテーブルを含む会社テーブルを取り上げます。
CREATE TABLE COMPANY (
company_id INT NOT NULL,
company_name VARCHAR(50),
PRIMARY KEY (company_id)
) ENGINE=INNODB;
CREATE TABLE USER (
user_id INT,
user_name VARCHAR(50),
company_id INT,
INDEX company_id_idx (company_id),
FOREIGN KEY (company_id) REFERENCES COMPANY (company_id) ON...
) ENGINE=INNODB;ON UPDATE句を見てみましょう。
そしてON DELETE側で：
通常、私のデフォルトはON DELETE RESTRICT ON UPDATE CASCADEです。いくつかON DELETE CASCADEのトラックテーブル（ログ-すべてのログではない-など）を使用ON DELETE SET NULLし、マスターテーブルがUSERテーブルのJOBテーブルのような外部キーを含むテーブルの「単純な属性」である場合。
編集する
私が書いてから久しぶりです。ここで、重要な警告を1つ追加する必要があると思います。MySQLには、カスケードに関する1つの大きな文書化された制限があります。カスケードはトリガーを起動していません。そのため、そのエンジンでトリガーを使用するのに十分な自信がある場合は、カスケード制約を避けてください。
MySQLトリガーは、SQLステートメントによってテーブルに加えられた変更に対してのみアクティブになります。ビューの変更や、SQLステートメントをMySQLサーバーに送信しないAPIによって行われたテーブルの変更によってアクティブ化されません。
==>最後の編集の下を参照してください、物事はこのドメインで動いています
トリガーは、外部キーアクションによってアクティブ化されません。
そして、これはいつか修正されるとは思いません。外部キー制約はInnoDbストレージによって管理され、トリガーはMySQL SQLエンジンによって管理されます。両方が分離されています。Innodbは、制約管理を備えた唯一のストレージです。おそらく、ストレージエンジンに直接トリガーを追加するかもしれませんが、そうしないかもしれません。
しかし、私はあなたが貧弱なトリガー実装と非常に有用な外部キー制約サポートの間で選択すべき要素について私自身の意見を持っています。そして、データベースの整合性に慣れると、PostgreSQLが気に入るはずです。
コメントで@IstiaqueAhmedが述べたように、この件に関して状況は変わりました。したがって、リンクをたどって、実際の最新の状況をチェックしてください（将来は再び変更される可能性があります）。
SET NULLにはON UPDATE会社の更新は会社>ユーザ関係の離脱を表します。例：会社がそのビジネスタイプを変更した場合、以前のユーザーはそのビジネスに関連しなくなっているNULL可能性があるため、このインデックスに適している可能性があります。
This includes changes to base tables that underlie updatable viewsあなたが貼り付けたものの代わりに言いますThey do not activate for changes in views
CASCADE DELETE一般的に、また大丈夫でも好ましいです。特に危険だとは思いません。
@MarkR回答への追加-注意すべき1つの点は、ORMを使用する多くのPHPフレームワークが高度なDBセットアップ（外部キー、カスケード削除、一意の制約）を認識または使用しないため、予期しない動作が発生する可能性があることです。
たとえば、ORMを使用してレコードをDELETE CASCADE削除し、関連テーブルのレコードを削除する場合、ORMがこれらの関連レコードを削除しようとすると（多くの場合は自動）、エラーが発生します。
アプリケーションのコンテキストでこれを考慮する必要があります。一般に、データベースではなくアプリケーションを設計する必要があります（データベースは単にアプリケーションの一部です）。
アプリケーションがさまざまなケースにどのように対応するかを検討します。
デフォルトのアクションは、操作を制限する（つまり、許可しない）ことです。これは、愚かなプログラミングエラーを防ぐために通常必要な操作です。ただし、DELETE CASCADEの場合も役立ちます。これは、実際にはアプリケーションと、特定のオブジェクトをどのように削除するかによって異なります。
個人的には、FK制約があるのではなく、データを破棄しないため（MyISAMを参照）、InnoDBを使用します。
ON DELETE CASCADE : dangerous-ひとつまみの塩で服用してください。