ディレクトリとファイルのファイルシステム階層を格納しています。同時にデータテーブルと検索テーブルのカスケード削除
innodbテーブルでは、各ディレクトリ/ファイルの詳細を保存し、削除時にカスケードする外部キー制約との親子関係を維持します。
myisamテーブルは、フルテキスト検索でこれらのディレクトリ/ファイルを検索するために使用されます。各行の名前とIDが含まれています。
データテーブル（innodbテーブル）のどの行も検索テーブル（myisamテーブル）に対応する行を持ち、データテーブルの行の追加または削除を検索テーブルに反映する必要があります。
親ディレクトリを削除するときに、2つのテーブル間のデータの一貫性を維持するための最良のソリューションを見つけようとしています。 innodbテーブルは大丈夫です。私は親を削除し、削除はすべて削除されるまで子を介してカスケードします。 myisamテーブルから対応する行を削除することはより困難です。
私の最初の考えは、innodbテーブルでon-deleteトリガを使うことでした。行が削除されると、myisamテーブルから対応する行が削除されます。しかし、カスケード削除時にMySQLがトリガを起動しないため（マニュアルでサポートが不足していることが修正された7年間の既知のバグ）、これはオプションではありません。
私は、検索テーブルに親子関係を置いていましたが、フルテキスト検索機能をサポートするのはmyisamテーブルなので、外部キー制約はサポートされていません。
私はinnodbが全文検索をサポートするようになったので、検索テーブルエンジンを変更できると思ったが、実験室でのみ利用できると思った。
私の最後の考えは、外部キーの制約を破棄し、データの整合性を維持するためにトリガーのみを使用することでした。削除時に、innodbとmyisamの両方のテーブル（parent = OLD.id）から削除します。ただし、テーブル内のすべてのデータを破壊する可能性のある無限ループを防ぐため、MySQLはトリガーを有効にした同じテーブル内のデータの操作をサポートしていません。
私は親ディレクトリの下のすべての子をプログラムの要求ループで取得することに頼っていましたが、より良い選択肢があるはずです。 もっと効率的な方法はありますか？私が考えることができる唯一の2つのオプションは、上記のアプローチの1つが修正されるのを待っているか、カスケード削除からトリガを起動するPostgreSQLのような別のRDBMSに変更することです。
他のアイデアをいただければ幸いです。
2つのテーブル間の関係について、私はかなり混乱しています。お互いに異なるタイプの2つのテーブルの間の関係を定義することです。私は以前これを試して、データの一貫性を維持する際に問題が発生しました。もし、外部キーとプライマリキーのユーザーとのテーブル関係を通じてデータの一貫性を維持したい場合は、関係を定義するすべてのテーブルでinnodbを使用します。 –
検索テーブル（myisam）がデータテーブル（innodb）の検索エンジンとして使用されています。しかし、サブディレクトリとファイルを持つディレクトリが削除されると、変更はデータテーブルと検索テーブルの両方に反映される必要があります。全文検索がサポートされていないため、検索エンジンにinnodbを使用することはできません（少なくとも、当時）。リレーションシップはデータテーブルでうまく定義されますが、削除は検索テーブルに反映されません。 – JayceTDE
+1よく書かれた質問;残念ながら私はあなたの現在のアプローチに代わるものは見当たりませんが、他の誰かが何かを思いつくでしょう – Daan