はじめに
Ruby on Railsを学習していた際に知った「timestamps」について。
今までは意識せずこのコードを書いていましたが、必ず必要なものなのか、不要の時もあるのかどうかが分からなくなりました。
今回調べた内容を共有したいと思います。
Rails で t.timestamps は必ず付けるべき？不要になるケースはある？
そもそも「t.timestamps」によって何が自動生成されるのか
Rails のマイグレーションでは、次のように t.timestamps を書くことがよくあります。
t.timestamps
これを追加すると、以下の2つのカラムが自動生成されます。
- created_at：レコードが作られた日時
- updated_at：レコードが更新された日時
Rails はモデルを保存・更新するタイミングで、これらの値を自動で管理してくれます。
そのため、とりあえず付けておけば「後からデータの履歴がわかる」というメリットが大きいです。
timestamps を付けない方が良いケースもある？
基本的には 付けた方が便利 なのですが、つけない場合もあるそうです
以下は、役立つかもしれない「例外的なケース」になります
1. データがほとんど変化しない“定数テーブル”
例えば以下のようなデータは、アプリ全体で使う「固定データ」です。
- 都道府県
- 国名
- 料金プランの一覧
- カテゴリ一覧
これらはアプリで参照するだけで、基本的に更新は発生しません。
そのため、作成日時・更新日時を保存する必要がありません。
create_table :prefectures do |t|
t.string :name, null: false
end
2. 履歴管理が不要な「設定テーブル」
settings などのキー・バリュー型テーブルは、値が変わっても“いつ変わったか”を追跡しない場合があります。
create_table :settings do |t|
t.string :key, null: false
t.string :value, null: false
end
設定は必要な時に上書きされればよいだけなので、timestamps は必須ではありません。
3. 大量データを扱うテーブルで性能を重視したい場合
Rails はレコードを保存するたびに updated_at を必ず更新します。
大量データの逐次保存を行う場合、この更新処理が小さな負荷になります。
例：
- 1秒ごとにログを保存する IoT データ
- 大量のインポート処理がある参照テーブル
参照専用で、履歴管理も不要なら、省略するという選択肢があります。
4. ストレージを少しでも節約したいとき
created_at と updated_at は、それぞれ8バイトの日時データです。
大規模システムでは“少しでも節約したい”ことがあります。
timestamps を付けるメリット
Rails を学び始めた段階では、基本的に timestamps は付ける方が良いメリットは下記になります
✔ デバッグが圧倒的に楽（「いつ作られたか」がわかる）
✔ データの整合性が確認しやすい
✔ 予期せぬ更新やバグを発見しやすい
✔ 後で統計データを取るときに便利（新規数、更新数など）
特に、開発が進むほど「付けておけばよかった…」となることが多いです。
※私も後悔した経験があります💦
結論：基本は「付ける」。例外的な状況では「外す」。
| 状況 | timestamps |
|---|---|
| 通常の CRUD モデル | 付けるべき |
| データがほぼ変わらない定数テーブル | なくてもOK |
| 設定や参照専用で履歴不要 | なくてもOK |
| 大量データでパフォーマンスを最適化したい | 条件次第で外す |
| ストレージを極力減らしたい | 条件次第で外す |
迷ったら 付ける 方向でいいかと思います