TL;DR
データモデリングの手法の 1 つ。データモデルの段階で、UPDATE をできるだけ起こさないようにエンティティを設計する。
なぜ必要か
kawasima によると、CRUD のうち UPDATE がもっともシステムを複雑にする。更新を前提にしたモデルでは、更新に伴うルールが増えていく。UPDATE を減らすようにモデルを組むと、「One fact in one place」という正規化の原則も自然に満たせる。
仕組み
まず、エンティティをリソースとイベントに分ける。日時の属性を持つものがイベントで、業務上の行為の記録にあたる。リソースは「誰・何・どこ」にあたる実体である。
イベントのエンティティには、日時の属性を 1 つだけ持たせる。こうするとイベントは INSERT だけで記録でき、UPDATE が起きない。リソースに更新日時を持たせたくなったら、そこにイベントが隠れている可能性が高いので、それを別のエンティティとして切り出す。
一律に登録日時や更新日時を付けることはしない。変更の履歴が必要なら、変更前の状態を別のエンティティとして残す。依存しない 2 つのエンティティの関係は交差エンティティで表し、外部キーを後から更新する事態を避ける。
注意点
kawasima によると、「削除フラグ」や「削除日時」は悪だという設計思想が広まるのは良いが、物理設計のパターンで思考停止してはいけない。削除フラグを持たせたくなったら、まず更新日時と同じく、そのリソースにまつわるイベントを洗い出す。また、「マスタ」と「トランザクション」という分類は判別も使い道も曖昧で、自転車置き場の議論を招いて時間を無駄にすることがあるので、会話で使うのはよいが、設計ドキュメントやコードには使わない。