テーブルの created at にサービスのドメインロジックを持たせない - めもるが
前提 ActiveRecord の仕組みを用いてデータベースの migration を行っている。 主張 ActiveRecordでDBのマイグレーションファイルを作ると t.timestamps がデフォルトで指定されている。これをmig...
mkusakaActiveRecordのmigrationで付くt.timestampsのcreated_at/updated_atはメタ用途に限定し、whereやsort条件に使わず別カラムで保持すべきだと主張。
2026/09/14 05:54
Ep7TUEiW日付値がロジックを持つ ことは容易ではない。日付値を使うロジックを実装するのは容易だが。おそらく言語上の誤り
2026/09/14 07:55
snowcrushレコードがimmutableであればイベント時刻=created_atと見なしても実運用上そこまで問題は無いと思う。そういう意味では取り扱いが危ないのはupdated_atの方。
2026/09/14 08:10★★★★★★★
qtamaki積極的には用いないけど、カラム追加がめんどくさい時に見たりしている
2026/09/14 08:14★★★
turanukimaru例えば「その日の売り上げ」データを created_at で集計すると日付をまたいで営業したときにバグるし、システム障害とかでデータを入れなおすときに特定の日付で入れる必要がある。それよりは別に日付カラムを作るべき。
2026/09/14 08:19★★★
NetPenguinまったく同意なのだけど、最近のインターネット界隈、15〜10年くらい前に議論された事が再燃している印象がある。サロゲートキーの話とか。そのうち削除フラグの話も再燃しそうな気がする。
2026/09/14 09:32★
raamen07データの一括入れ直しをします！みたいなのがあると狂うよね
2026/09/14 10:14★
hasiduki危険だから使わないのもいいよね！！！！！！！
2026/09/14 10:21
auto_chanデータ移行とかメンテとかで差し込まれたレコードが破滅するのでやめとこう。
2026/09/14 10:44
fusionstar削除フラグなんかもそうだけど、データベースにおける意味と業務上の意味は分けないといけないね。 ログテーブルならいいと思うけどね。
2026/09/14 10:57
roshiカラムとして露出するんじゃなくて、ファイルシステムのようにレコードのメタデータとして自動的に付与されるといいんだけどなーと思う時はある。
2026/09/14 11:08
miki3kcreated_atはレコード作成日時であり、業務イベント発生日時ではない。集計条件などに流用せず、shipped_atのような専用カラムを別途用意すべき、という主張。
2026/09/14 11:16