CodeIgniterを使用してデータベース内で変更を記録する適切な方法は何ですか

Question

小さなCodeIgniterアプリケーション用の簡単な監査システムを作成したいと思います。エントリが編集される前に、テーブルエントリのスナップショットをとるようにします。私が考えることのできる1つの方法は、news_auditテーブルを作成することです。これはニューステーブルのすべての列を複製します。また、追加された日付の列が追加され、各変更に対して新しいレコードが作成されます。このような機能をPHP Webアプリケーションに組み込むというあなたの見解と意見は何ですか？

Answer 1

は、あなたが使用するソリューションを決定する前に考慮すべきいくつかの事があります

あなたのテーブルには、（または大きくなる可能性が）あなたの監査証跡は、あなたが説明するように別々のテーブルにする必要がありますか、大きい場合パフォーマンスが低下します。

新しいエントリを追加する場合を除いて（潜在的に）変更できない監査が必要な場合は、アプリケーション専用のINSERT権限が必要です（キャストアイアンを専用のログサーバーに配置する必要があります）... ）

監査レコードを別の開発者（日付なしで古いものを除外する必要があることに気づかないかもしれない）と混同してしまう可能性があるので、同じテーブルに監査レコードを作成しないでください。 dbが必要以上のディスク・ブロックをキャッシュするようにします（=パフォーマンス・コスト）。また、これを正しく索引付けするには、dbがNULLSを索引付けしない場合に問題があるかもしれません。最新のバージョンのクエリには、タイムスタンプすることを選択した場合はサブクエリが含まれます。

これを解決する最もクリーンな方法は、データベースでサポートされている場合、INSERT権限だけが必要な別の監査テーブルに古い値をコピーするUPDATE TRIGGERをニューステーブルに作成することです。このようにして、ロジックはデータベースに組み込まれているので、アプリケーションはそれを気にする必要はなく、データを更新するだけで、dbは変更ログを保持します。トリガーの本体はINSERTステートメントになります。前に記述していない場合は、それほど時間がかかりません。あなたは、私が例を投稿することができるかもしれません使用しているDB

私が知っていたら...我々は（そしてあなたのサイズや用途に応じて事前にアーカイブを設定したいと思う）けど、私たちが作成した何

Answer 2

ここではどのような規模ですか？平均して、頻繁にまたは頻繁に編集されるエントリはありますか？

平均アイテムに期待される編集回数に応じて、データの完全コピーではなく、大きなデータブロックのdiffを保存する方が理にかなっています。

Answer 3

私が気に入っている方法の1つは、テーブル自体に入れることです。単に 'valid_until'列を追加するだけです。行を編集するときは、その行をコピーして、古い行の 'valid_until'フィールドにスタンプするだけです。有効な行は 'valid_until'が設定されていない行です。要するに、あなたはそれをコピー・オン・ライトにします。主キーを元の主キーとvalid_untilフィールドの組み合わせにすることを忘れないでください。また、各IDに対してvalid_untilが設定されていない行が1つだけ存在するように制約やトリガーを設定します。

これには、面と欠点があります。テーブルの数が少なくて済む。欠点は、あなたのテーブルのはるかに多くの行です。古いデータに頻繁にアクセスする必要がある場合は、この構造をお勧めします。単純なWHEREをクエリに追加するだけで、以前の日付/時刻にテーブルの状態を照会することができます。

古いデータにアクセスする必要がある場合は、時折このデータを推奨しません。

Temportal databaseを作成することで、これを極限まで引き上げることができます。私は、ルールの次のセットを使用する中規模のプロジェクトに小規模で

Answer 4

：すべてのコード

1. はリビジョンコントロールシステム（つまり、Subversionの）
2. の下に格納されたソースコード内のSQLパッチのディレクトリは（ありすなわちpatches/）
3. このディレクトリ内のすべてのファイルはDBスキーマに対するすべての変更は、別々のファイルとして記録されなければならない短い説明に続いて、シリアル番号（すなわち086_added_login_unique_constraint.sql）
4. で始まります。バージョン管理システムにチェックインした後、ファイルを変更することはできません。すべてのバグは、別のパッチを発行して修正する必要があります。このルールに密接に従うことが重要です。
5. 小さなスクリプトは、ローカル環境で最後に実行されたパッチのシリアル番号を記憶し、必要に応じて後続のパッチを実行します。

これにより、データ・ダンプ全体をインポートせずに簡単にDBスキーマを再作成できます。このようなパッチを作成することは簡単なことではありません。コンソール/ UI/Webフロントエンドでコマンドを実行し、成功すればコピーしてパッチに貼り付けてください。次に、それをrepoに追加して変更をコミットします。

このアプローチは、合理的にうまくスケールされます。 1300+クラスと200以上のテーブル/ビューで構成されるPHP/PostgreSQLプロジェクトに取り組みました。

Answer 5

ユーザー情報、時間、およびXMLの変更をテーブル名とともに格納する監査テーブル。

SQL2005 +を使用している場合は、必要に応じてXMLを簡単に検索できます。

は、我々はその後、

は、単純な直列化して、我々は復元し、変更を複製することができます（...挿入、削除、更新）我々が監査したいものをキャッチするために、私たちのテーブルにトリガを追加しました。