Одновременное каскадное удаление таблицы данных и таблицы поиска

Я сохраняю иерархии файловой системы каталогов и файлов.

В таблице innodb я храню сведения о каждом каталоге/файле и поддерживаю родительско-дочерние отношения с ограничением внешнего ключа, которое будет каскадным при удалении.

Таблица myisam используется для поиска в этих каталогах/файлах с помощью полнотекстового поиска. Он содержит имена и идентификаторы каждой строки.

Любые строки в таблице данных (таблица innodb) будут иметь соответствующую строку в таблице поиска (таблица myisam), и добавление или удаление строк из таблицы данных должно отражаться в таблице поиска.

Я пытаюсь найти лучшее решение для обеспечения согласованности данных между двумя таблицами при удалении родительского каталога. Таблица innodb в порядке. Я удаляю родителя, удаление каскадом проходит через дочерние элементы, пока они все не будут удалены. Удалить соответствующие строки из таблицы myisam сложнее.

Моей первой мыслью было использовать триггер удаления для таблицы innodb. Когда строка удаляется, она удаляет соответствующую строку из таблицы myisam. Однако, поскольку MySQL не активирует триггеры во время каскадного удаления (известная ошибка за 7 лет, которую исправили, упомянув об отсутствии поддержки в руководстве), это не вариант.

Моя вторая мысль заключалась в том, чтобы поместить отношение родитель-потомок в таблицу поиска, но это таблица myisam для поддержки функций полнотекстового поиска, и поэтому она не поддерживает ограничения внешнего ключа.

Я слышал, что innodb теперь поддерживает полнотекстовый поиск, поэтому я подумал, что, возможно, я мог бы изменить механизм таблицы поиска, но он доступен только в тестовой версии.

Последней моей мыслью было отказаться от ограничений внешнего ключа и использовать только триггеры для обеспечения согласованности данных. При удалении удалите из таблиц innodb и myisam, где parent = OLD.id. Однако, чтобы предотвратить бесконечные циклы, которые могут повредить все данные в таблице, MySQL не поддерживает манипулирование данными в той же таблице, которая активировала триггер.

Я прибегал к программному извлечению всех дочерних элементов в родительском каталоге через цикл запросов, однако я чувствую, что должен быть лучший вариант. Есть ли какие-либо другие обходные пути, которые были бы более эффективными?На данный момент я могу придумать только два варианта: ожидание исправления одного из вышеперечисленных подходов или переход на другую СУБД, такую ​​как PostgreSQL, которая поддерживает запуск триггеров из каскадного удаления.

Будем признательны за любые другие идеи.