Rails の timestamps カラム(created_at, updated_at) と別に日時カラムを作る理由が分からん

Rails を使っていて、日時カラムを作るケースがありますが、あれのメリットが知りたいと思って、ブログに書いてみた。

例: ユーザーの登録日時

# db/migrate/20161010010101_create_users.rb
class CreateUsers < ActiveRecord::Migration
  create_table :users do |t|
    t.string :name
    t.datetime :registered_at, null: false

    t.timestamps null: false
  end
end

こんな感じで、ユーザーの登録日時を created_at を使わず、 registered_at のように別カラムを用意して、自分たちで Time.now などを保存するような実装のメリットが知りたい。

timestamps で良いと思っている理由

カラムを使い分けることがほぼない

よく「レコード挿入日時と登録日時は意味が違う」という意見をお聞きするのですが、「ユーザーが登録するとレコードが1件できる」という事を考えると、そこまで意味が違うものなのか疑問。

そもそも「レコード挿入日時」と「登録日時」と使い分ける仕様がほぼ無い。(後述する非同期処理くらい?)

使った方が楽

ActiveRecord が自動的に生成するものを使うべきじゃない」って話も聞くけど、用意されている機能を使った方が冗長にコード書かなくて済むし、自分たちで再実装するより良いのでは? belongs :user, touch: true とか使えて便利ですし。

cache に使われる

標準だと View の cache で Modle の updated_at が使われるので、 updated_at を最終更新日としておいて方がシンプルに Rails のレールに乗れて良い。

日時カラムを別に用意する方が良いと思うケース

非同期処理を使う

「非同期処理(または登録処理)に時間がかかり、ユーザーのリクエスト 〜 DB挿入に時間がかかる」場合、値がズレるので別カラムは必要かもしれない。そのズレが問題になる仕様の場合は。

単純な更新日時じゃない場合

「特定のカラムが更新されたときだけ、更新日時を更新したい」みたいな仕様の場合は updated_at とは別にカラムを用意した方が良いと思う。

  • あえて非正規形なテーブルにしている
  • 既存のDB設計が腐っているが、直せない

みたいなケースだと、 updated_at をそのまま活用するのは難しいと思う。

まとめ

DB設計に問題がなければ、基本的には Rails 標準の timestamps を使って良いのではないかと思っています。

もし、別の考えなどあればコメントなど頂けると嬉しいです。