以下に私の懸念を書きましたが、この質問は「監査」と「ロギング」に関連しています。
基本的なステートメントのログ記録は、General Query Logを使用して実現でき、より高度な監査はEnterprise Auditプラグインで実行できます。トリガーはクエリのログ記録には適していませんが、変更ログ証跡の更新/挿入を実装することが知られています。
プログラムで使用法を見つけようとするのは間違っていると思います。リファクタリングは「進行中の」プロセスではありません。(リファクタリングの目標ごとに) 1 回行われれば、人生は続きます。テスト (例: ユニット/統合) とコード カバレッジは、リファクタリングの結果を伝えることができますが、通常、形式化されたDAL /API で最もうまく機能します。
代わりに、これはコードベースに腰を下ろし、すべてのデータベース アクセス コールを注意深く分析する良い機会です。のようなひどい列名でさえ、id
特定の出現箇所を見つけようとするだけであれば、比較的簡単にファイルを検索できます。手動での変更について「快適に感じる」のに 1 時間か 2 時間しかかからない可能性があります。さて、そのような変更だけをテストできれば..
また、すべてのアクセスを適切に定義されたコントラクトを持つ名前付きメソッドにリファクタリングすることも賢明です。これは、現在呼び出しサイトに残っている場合でも、後で適切な DAL にプッシュすることができます。この関心の分離は、テスト容易性と将来のリファクタリングを支える基礎です。