🤔

created_at と updated_at のあつかい

結論

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

なぜ created_atupdated_at を参照しないのか

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

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

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

他にも、

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

なんて理由もあるらしい1

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

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

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

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