DateLastUpdated のような名前のデータベース テーブルの列を参照する質問が浮かんでいるのをよく見かけます。理解できません。
私が今まで見た唯一のコンパニオン フィールドは、LastUpdateUserId などです。更新が行われた理由についての指標はありません。または更新が何であったかさえ。
その上、このフィールドはトリガー内から書き込まれることがあり、使用できるコンテキストがさらに少なくなります。
確かに、監査証跡にはほど遠いものです。だから正当化できない。また、ログなどのどこかに監査証跡がある場合、このフィールドは冗長になります。
私は何が欠けていますか？このパターンが人気の理由は？
このようなフィールドは、異なるプロセスによって行われた競合する編集があるかどうかを検出するために使用できます。データベースからレコードを取得すると、以前の DateLastUpdated フィールドが取得されます。他のフィールドに変更を加えた後、レコードをデータベース レイヤーに送信します。データベース層は、送信した DateLastUpdated がデータベース内のものと一致することを確認します。一致する場合、更新が実行されます (そして DateLastUpdated が現在の時刻に更新されます)。ただし、一致しない場合は、その間に他のプロセスがレコードを変更したため、現在の更新を中止できます。
正確な状況にもよりますが、そのようなタイムスタンプは、自動生成されたデータに非常に役立ちます。後で依存関係が変更された場合に、何かを再計算する必要があるかどうかを判断できます (これは、ビルド システムがどのファイルを再コンパイルする必要があるかを計算する方法です)。 ）。
また、多くの Web サイト、特にコンテンツを編集する可能性のあるニュース サイトでは、ページに「最終更新日」を示すデータがあります。正確な理由は必要ありません (また、監査証跡が本当に必要な場合に備えてバックアップが存在する可能性があります) が、このデータはエンド ユーザーに表示される必要があります。
いくつかのシナリオがあります
顧客のアドレス テーブルがあるとします。CRM アプリがあり、1 か月前に住所が変更されたと顧客から電話があり、LastUpdate 列を使用して、この顧客のこの行が 4 か月間変更されていないことがわかります。
通常、トリガーを使用して履歴テーブルに入力し、他のすべての履歴を表示できるようにします。作成日と更新日が同じであることがわかった場合は、何も見つからないため、履歴テーブルにアクセスしても意味がありません。
インデックス（株式市場）を計算すると、この列を見るだけで再計算されたことが簡単にわかります
2 つの DB サーバーがあり、日付列を比較することで、すべての変更が複製されたかどうかなどを確認できます。
これらの種類のものは、通常、更新を開始するためにユーザーの操作が必要なビジネス アプリケーションに使用されます。通常、何らかの種類のビジネス アプリ (CRM デスクトップ アプリケーションなど) があり、ほとんどの更新では、更新を行う方法が 1 つしかない傾向があります。
住所データを見ている場合、それは「住所の維持」画面などで行われました。
このようなデータベース監査は、ビジネス レベルの監査を強化するためのものであり、それを置き換えるものではありません。コール センターでは、通話を録音することがあります (オーストラリアの金融サービス プロバイダーの場合は常に)。これも監査証跡の一部ですが、デスクトップ アプリケーション (および関連するインフラストラクチャ) に関する限り、IT ソリューションの一部になる傾向はありません。
コール センターのスタッフは通常、何らかの「メモ」または「ログ」機能を備えており、顧客が電話をかけた理由と、次のオペレーターが顧客の呼び出し時に中断したところから再開できるように、フリーフォーム テキストを入力できます。戻る。
トリガーは、変更内容を正確に記録するためによく使用されます (たとえば、古いレコードを監査テーブルに書き込むなど)。このすべての目的は、すべての情報 (メモ、記録された通話、データベースの監査証跡、およびログ) を使用して、データの以前の状態を再構築し、結果のアクションを再構築できるようにすることです。これは、システムのバグを見つけて解決するため、または単に顧客との競合解決プロセスとして行う場合があります。
これは確かに人気があります。たとえば、Rails には作成時のタイムスタンプ (:timestamps) と同様に省略形があります。
同じパターンがビューで非常に一般的であるため、アプリケーション レベルでは非常に便利です。たとえば、こちらの質問を見てください (56 秒前に回答されたものなど)。
レポートで統計を生成するために遡及的に使用することもできます (DB 内のレコード数の成長曲線など)。
これは、デルタ フィードであるクライアントにフィードを送信する必要がある場合にも非常に役立ちます。これは、最後のフィードのデータが送信されてから変更または挿入されたレコードのみです。