タスクは、すべてのテーブルで削除ログを作成することですが、既存のテーブルまたは将来作成されるテーブルにオーバーヘッドを追加しません。つまり、DB のアップグレード時に: 1. DB 内のすべてのテーブルの情報スキーマをループします。 2. ループで、既存のトリガーを削除して削除します (必要に応じてトリガー ロジックを更新できるようにします) 3. 再びループで、再作成します。削除のトリガー
ストアド プロシージャの制限を調べると、いくつかの問題で壁にぶつかったと思います。これが私がやろうとしていたループです:
DELIMITER $$
DROP PROCEDURE IF EXISTS create_delete_triggers $$
CREATE PROCEDURE create_delete_triggers()
BEGIN
DECLARE done int default false;
DECLARE tblname CHAR(50);
DECLARE cur1 CURSOR FOR SELECT TABLE_NAME FROM INFORMATION_SCHEMA.tables WHERE TABLE_SCHEMA = 'app_db' AND TABLE_NAME LIKE 'obj%' ;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
OPEN cur1;
deleteloop: LOOP
FETCH cur1 INTO tblname;
IF done THEN
LEAVE deleteloop;
END IF;
-- ANY SORT of function I can do here to set triggers on these
SELECT tblname, DATABASE();
END LOOP;
CLOSE cur1;
END $$
DELIMITER ;
まず、準備されたステートメントを含むストアド プロシージャは no go のように見えますが、これはショー ストッパーのようです。理想的な世界では、私のカーソル ブロックは、これを行う準備済みステートメントを実行します。
DELIMITER $$
CREATE TRIGGER del_row_table_name AFTER DELETE ON tblname
FOR EACH ROW
BEGIN
-- use old row to marshall a row to store its primary key, time of deletion, and tablename
END $$
DELIMITER ;
つまり、基本的に、これを解決するために目に留まらなかった MySQL の凝ったものを探し回っています。反対に、それができないことを知っておくとよいでしょう。開発チームにオーバーヘッドを導入する必要があることを受け入れます。