Rails を使っていて、日時カラムを作るケースがありますが、あれのメリットが知りたいと思って、ブログに書いてみた。
created_at を使わず、あえて自分達で 別のカラムに https://t.co/BzSE87AzJJ を保存する実装にする意味が分からん…。非同期処理で時間がズレるのを避けるとかならともかく、それ以外で作る意味あるのかなぁ…。
— 神速@リリカルエンジニア (@sinsoku_listy) 2016年10月10日
例: ユーザーの登録日時
# 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 を使って良いのではないかと思っています。
もし、別の考えなどあればコメントなど頂けると嬉しいです。