RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々

RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_

[Songmu]

blogged.

[Windymelt]

ウム…… > “多少冗長な情報はいざという時にあなたの身を助けてくれます”

[Knoa]

最後の "created at" と "last modified at" がきれいなオチに見えて仕方がない

[sainu]

updated_atをアプリケーション側の意味合いで利用した時、ここに書かれた想定どおりアプリケーション側の仕様変更（下書き機能追加など）で爆死した。良い教訓

[karikari1255]

だからRailsというかActiveRecordの暗黙的な仕様が大嫌いだった。DBのトリガーじゃないんかい、他言語からもDB触るんですけどって

[cl-gaku]

同じトランザクションの更新日を揃えたいマンの上司が出てきて地獄化するんだよなぁ

[i178inaba]

基本created_at、updated_atは全テーブルに付けるルールにしておけば思わぬ運用作業の時とか楽になりますよね。

[endok]

良い。

[SWIMATH2]

ほんまそれ～（今のプロジェクトで負債になってる）

[snicmakino]

次作るシステムで参考にします！メリットははっきり分かるけど、自分が対応するときには冗長な内容の項目を作るのが一歩踏み出せないから、こういうやり方を明示してくれるだけで凄くハードル下がる

[koba789]

もっとも、binlog を保管しておく仕組みがあれば調査記録用のデータは用無しであり、削除を追えないこの仕組は中途半端である(手軽なので雑なケースでは便利だが)

[juve534]

"アプリケーションから使うのであれば、汎用的な名前ではなく意味のある名前にすべき"

[griefworker]

.NET の Entity Framework Core の場合はシャドウプロパティで実現できるかも。/更新が結構無理やりだったのでトリガー使うのが無難だった。

[msykt]

“つまり、created_atとupdated_atはRDBのドメインの上で「レコードが作成された時刻・更新された時刻」以上の意味を持たないことに価値があるのです。”

[tmatsuu]

ログでいいかどうかについては、ログをアプリケーションで参照しはじめたらISUCONでもよくあるマズイ実装との認識。ON UPDATE CURRENT_TIMESTAMPは結構古くからあるので、もしかしたらTRIGGERとは別の仕組みかも。

[posmaru1]

created_atとupdated_atはサービス作ってる時には要らないかなと思う事が多いけど、運用では欲しくなることが多いから設計というより対象業務の運用理解や運用経験に依存してると感じさせられる

[khtno73]

こればかりは「思考停止してとりあえずつけとく」でいい気がする。

[ntaoo]

とても良く分かる。FirestoreなどのNoSQLにも当てはまる

[jsstudy]

created_atとupdated_atはRDB上で「レコードが作成された時刻・更新された時刻」以上の意味を持たないことに価値がある。RDBのトリガーでデータを埋めた方が良い。アプリケーションから参照するカラム名は意味のある命名を

[natu3kan]

わかりみが深い＞"多少冗長な情報はいざという時にあなたの身を助けてくれます"

[kenjiro_n]

MySQLでは登録更新時に時刻を自動挿入してくれる仕組みがあるとのこと。Oracleでこういう仕組みがあるのかを調べたい。/トリガーを使うといいのか。そうか。

[uunfo]

あれってORMの機能じゃなくてDB側のビルトインだったのか／前に一度調べたような気もする

[n314]

ブコメ見てトランザクションの更新日が揃ってるのは普通じゃないかと思ったけどPostgreSQLだけだった。

[dev0000_1]

RDB側の時間管理設定の手間を嫌ってトリガーあまり使ってない。ちなみに Azure SQL Databaseとかだとタイムゾーンが通常UTC固定（豆知識）

[yarumato]

“レコード作成日時 created_at や更新日時 updated_at をRDBで自動挿入するのは便利。ただ、アプリからそのカラムを参照せず別に定義した方が良い。なぜか。トリガーにアプリロジックが依存しすぎ密結合になるから”

[turanukimaru]

例えば消費税なんかはあらかじめデータを入れておいてPublished_atを10/1にしておくとかにはした。update_at はLogというかVer.扱いだな。予期しない更新や更新し忘れを検出するために使うし目視でバグに気が付くことも多い。

[masayuki5160]

なるほど

[masatotoro]

jpaで@PrePersistと@PreUpdateで乗り切っていました

[hdampty7]

MySQL以外だと古くからそういう機能ある訳で今更感満載。

[nurupoeb]

わかる

[wwolf]

わかりみ