5
監査ログのデータベース設計
新しいデータベースを設計する必要があるたびに、変更の監査ログを保持するためにデータベーススキーマをどのように設定するかについてかなりの時間を費やしています。 これについてはすでにいくつかの質問がここで行われていますが、すべてのシナリオに単一の最良のアプローチがあることに同意しません。 改訂のためのデータベース設計 変更ログ監査データベーステーブルの最適な設計 監査証跡をキャプチャするためのデータベース設計に関するアイデア また、データベースの変更のログを管理するという興味深い記事に出会い、各アプローチの長所と短所をリストアップしようとしました。それは非常によく書かれていて興味深い情報がありますが、それは私の決定をさらに難しくしました。 私の質問は、私が使用できる参照、おそらく本や決定木のようなものであり、いくつかの入力変数に基づいてどの方向に進むべきかを決定するために参照できますか？ データベーススキーマの成熟度 ログのクエリ方法 レコードを再作成する必要がある確率 さらに重要なこと：書き込みまたは読み取りのパフォーマンス ログに記録される値の性質（文字列、数値、ブロブ） 利用可能な収納スペース 私が知っているアプローチは次のとおりです。 1.作成および変更された日付とユーザーの列を追加する テーブルの例： id value_1 値_2 value_3 作成日 modified_date によって作成された 変更された 主な短所：変更の履歴が失われます。コミット後にロールバックできません。 2.テーブルのみを挿入する 表の例： id value_1 値_2 value_3 から に 削除（ブール） ユーザー 主な短所：外部キーを最新に保つ方法は？巨大なスペースが必要 3.テーブルごとに個別の履歴テーブルを作成する 履歴テーブルの例： id value_1 値_2 value_3 value_4 ユーザー 削除（ブール） タイムスタンプ 主な短所：すべての監査済みテーブルを複製する必要があります。スキーマが変更された場合、すべてのログを移行するためにも必要になります。 4.すべてのテーブルの統合履歴テーブルを作成する 履歴テーブルの例： table_name …