created_at と updated_at のあつかい

結論

• created_at と updated_at をアプリケーションが参照することは基本的にしない
• updated_at が不要だと思われる場合でも、よっぽどの理由がない限りつくっておくのが無難

なぜ created_at や updated_at を参照しないのか

created_at と updated_at は RDB が値を格納する RDB ドメインのカラムであり、あくまで「レコードが作成された日時」と「レコードが更新された日時」をあらわしている。 アプリケーションがそれ以上の意味をもたせるのはよろしくない。

よって、created_at や updated_at を参照すれば済む場合でも、別にカラムをつくったほうがいい。 たとえば、記事の公開日は published_at、編集日は edited_at など。 これには、カラム名をアプリケーションのドメインによせる意味合いもある。 なお、published_at や edited_at はアプリケーションが明示的に値を指定する。

あと場合によっては、イベントが発生した時間 (先の例だと公開日、編集日）と RDB に記録された時間の差異が無視できなかったりする。 特に、ログや履歴のテーブルには注意が必要。

他にも、

• RDB とアプリケーションが密結合になる
• 仕様変更のときに困ることがある

なんて理由もあるらしい¹。

なぜ updated_at をつくっておくのが無難なのか

これは単純に、変更されない想定のレコードでもなにかしら変更されたときにそれを検出したいから。 設計を変えやすいというもあるか。 もちろん、

ユーザが操作しないマスタ系のテーブルで deploy 時にそのデータを埋めるフローなのであれば、作成時刻や更新時刻は不要でしょう¹

という意見もある。こちらのほうがいい気もしてきた。