ディレクトリとファイルのファイルシステム階層を保存しています。
innodb テーブルでは、各ディレクトリ/ファイルの詳細を保存し、削除時にカスケードする外部キー制約を使用して親子関係を維持します。
myisam テーブルは、全文検索でこれらのディレクトリ/ファイルを検索するために使用されます。各行の名前と ID が含まれています。
データ テーブル (innodb テーブル) 内のすべての行は、検索テーブル (myisam テーブル) 内に対応する行を持ち、データ テーブルから行を追加または削除すると、検索テーブルに反映される必要があります。
親ディレクトリを削除するときに、2 つのテーブル間のデータの一貫性を維持するための最適なソリューションを見つけようとしています。innodb テーブルは問題ありません。親を削除すると、子がすべて削除されるまで削除がカスケードされます。myisam テーブルから対応する行を削除するのはより困難です。
私が最初に考えたのは、innodb テーブルで on-delete トリガーを使用することでした。行が削除されると、対応する行が myisam テーブルから削除されます。ただし、MySQL はカスケード削除中にトリガーをアクティブ化しないため (7 年間の既知のバグで、マニュアルでサポートの欠如を言及することで修正されました)、それはオプションではありません。
私の 2 番目の考えは、親子関係を検索テーブルに入れることでしたが、これは全文検索機能をサポートするための myisam テーブルであるため、外部キー制約をサポートしていません。
innodb が全文検索をサポートするようになったと聞いていたので、検索テーブル エンジンを変更できるのではないかと考えましたが、ラボ リリースでしか利用できません。
私の最後の考えは、外部キー制約を放棄し、トリガーのみを使用してデータの一貫性を維持することでした。削除時に、parent = OLD.id である innodb と myisam テーブルの両方から削除します。ただし、テーブル内のすべてのデータを破損する可能性のある無限ループを防ぐために、MySQL は、トリガーをアクティブ化した同じテーブル内のデータの操作をサポートしていません。
リクエストのループを通じて、親ディレクトリの下にあるすべての子をプログラムで取得することに頼りましたが、より良いオプションが必要だと感じています。より効率的な他の回避策はありますか？この時点で、私が考えることができる唯一の 2 つのオプションは、上記のアプローチのいずれかが修正されるのを待つか、カスケード削除からのトリガーの起動をサポートする PostgreSQL のような別の RDBMS に変更することです。
他のアイデアは大歓迎です。