データベーステーブルはいつタイムスタンプを使用する必要がありますか？

まず、この質問はデータベース交換に属していると思いましたが、データベースよりもプログラミングソリューション全体に関連していると思います。人々がそれを最高だと思うなら、データベース交換に移行します。

データベーステーブルに作成および更新されたタイムスタンプをいつ追加する必要があるのか​​疑問に思いましたか？

最初の明らかな答えは、何かが更新されたとき（トランザクション完了日など）をビジネスロジックが知る必要がある場合、それを入力する必要があるということです。

しかし、非ビジネスロジックの場合はどうでしょうか。たとえば、いくつかのビジネスロジックが失敗し、関連するデータベースの行を確認して、1つの行が更新される前に識別することができるなど、障害の検出に役立つように行が変更された日時を知ることが本当に役立つシナリオを考えることができますエラーの原因となっている別の行。

このユースケースでは、すべてのテーブルに更新を与えてタイムスタンプを作成することは理にかなっています（アプリケーションのどの部分によっても更新されない最も単純な列挙テーブルを除く）。

すべてのテーブルにタイムスタンプを与えることは、間違いなくデータベースをすぐに停止させる素晴らしい方法です。

それでは、データベーステーブルはいつタイムスタンプの作成と更新を使用すべきですか？

より優れた包括的なデータベース管理を行うために、最も賢明な実践はそうすることです。

まず、開発者としての可能性が高いため、データベーストランザクションやアクティビティの開発を追跡し、データベースに関係するコードのバグやエラーの追跡を容易にする必要があります。

また、統計目的のためにデータベースで行われたアクティビティを追跡する必要があるときはいつでも。

もう1つは、当面の間はデータベースアクティビティを追跡する必要がないかもしれませんが、将来はそうなる可能性が高いことです。今日はあなたの時間を必要としますが、将来的にはより多く購入します。

密猟者（開発者）とゲームキーパー（DBA）の両方である人として、私は多くの人がまだこれに価値を見出せず、肥大化していると考えています。

簡単に言えば：

レコードが追加されている（ただし、更新されていない）テーブルの場合（ログインなど）、DATE_CREATED列の追加を検討します。

レコードが追加および更新されるテーブルについては、DATE_CREATED列とDATE_UPDATED列を追加することを検討します。

DATE_CREATEDとDATE_UPDATEDが設計の一部としてデフォルトですべてのテーブルに含まれる多くの場所で働いてきました。

データベースの更新が数日間にわたって実行された数百万行または数十億行の大規模なデータベースの場合、サードパーティフィード、ユーザー更新、DBA変更など、どのデータポットが更新を引き起こしたかを追跡するいくつかのテーブルのSOURCE列も追加しました。データクレンジングなど

質問の言い回しの仕方、あなたは物事のリストを求めています。私はあなたの質問に直接答えるのではなく、代わりの解決策を使用すべきときに答える危険を冒します。

障害の発見に役立つように行が変更された日時を知ることが本当に役立つシナリオを考えることができます

特定のレコードのすべての更新のログを保持する方が便利でしょうか？最後の更新を知っているだけでは、十分な情報ではないかもしれません。このログは別のテーブルに置くことができます。同じログファイル内の複数のテーブルからの変更を追跡する方が便利です（テーブルである必要はありません）。これにより、すべてのテーブルchange_datesの大規模なユニオンクエリが集計を取得できなくなります。これは、システム内のより多くのイベントの記録を確認できるようにすることで、トラブルシューティングにも役立ちます。

さらに：ユーザーも考慮する必要があります。彼らはそれをビジネスケースにしないかもしれませんが、経験の浅いユーザーや、ユーザーエラーを決して犯さず、常にコンピューター上でそれを責めたい企業文化のユーザーがいる場合、あらゆる種類のロギングがテーブルの更新日を含むのに役立ちます。この場合、Update_UserIDフィールドも必要になる場合があります。

次のいずれかに該当する場合、データベーステーブルに作成および変更テンプレートを含める必要があります。

1. この表は、ユーザーが提供したアクティビティのプライマリレコードを表します。ユーザーがXを実行し、a Table_Xとaの両方Table_Yが1対多の子であるTable_X場合、Table_Yはプライマリレコードではないため、追加のフィールドは不要です。
2. システムトラッキングが永続的、一時的、または繰り返し必要な場合。Table_Y更新されたときにのみ更新されることを確認する必要がある場合Table_Xは、追加の追跡フィールドが役立ちます。

これらはどちらも排他的ではないことに注意してください。デフォルトでどこにでもそれらを追加し、パフォーマンスチューニングに必要な場合のみ省略できます。

個人的な意見：

modified列に値が表示されません。

created、絶対に、それを行わない例外的な理由がない限り、すべてのデータベーステーブルに追加する必要があります。そこにあることはとても価値があります。

しかし、updated無駄に思えます。どうしても独り占めにしないで、2つのデータベーステーブルを作成します。1つはドキュメントIDを指定し、もう1つはドキュメントバージョンを指定します。非常に単純な場合

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

次にversion、document必要な最新のものを選択します。このようにして、最後の日付だけでなく、すべての変更日を保存するだけでなく、そのドキュメントのすべてのバージョンを保存することもできます。それに対する唯一の議論は、実際にはハードドライブのスペースですが、どのハードドライブのスペースが使い果たされているのか悩んでいるときは、確かに-ほとんどの場合、データのバージョン管理についてさらに悩まされます