Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス

読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ

[lainof]

updated_atがレコードの更新日時を表すなら強制的に更新すべきじゃない？(指定できちゃうと信用できなくなる)そうすればトリガーは一つで済む。業務的な更新日時が必要なら別の列を設けてアプリから更新した方が良い。

[hotmilkcocoa]

関係ないけど PostgreSQL 10 からは serial じゃなくて generated as identity を基本使うべきっていう話がある

[dagama]

だいたい分散しなくていいことの方が多いので連番で済ませちゃうやつ

[taruhachi]

updated timestampはシステムで自動的に発行するものと、アプリケーションで管理するものと二重管理するべきと思ってる。理由はDB間のデータマイグレーションなどでバックデートで入れたい時などはある為。

[n314]

serialが基本だしタイムゾーン使ってないしあんまり共感できないなあ。分散環境ならserialの選択肢がなくなるから分散前提かと思えばmysqlを見るとそうでもないみたいだし。updated_atはトリガー一つでNEW!=OLD入れてる。

[nmcli]

なるほど UPDATE するたびに CURRENT_TIMESTAMP にしたいが、updated_at のカラムを直接いじるときは対象外にしたい、を実現しようとするとこうなるのか。トリガーだけでなんとかなるのね。

[circled]

MySQL：「世界は1970年に始まった(タイムスタンプを眺めながら)」 vs Postgres：「で、でたぁー、宇宙は3分前に始まったとしても問題無いとか哲学ぶっちゃう奴〜」

[shag]

そうか。分散前提だと UUIDv4 のほうが便利なのか。serial 型というか sequence の管理割と面倒だしな。

[nilab]

Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス

[miguchi]

“created_at updated_at”

[rochefort]

uuid

[tmatsuu]

UUIDv7知らなかったんだけど、新たにUUIDv6, UUIDv7, UUIDv8 ってのがdraftになっていることを知った。昔英語の記事でbigint vs uuidってのを見かけたな。わいわい

[kamm]

そろそろ分散、シャーディングを考慮に入れた新時代のRDB出てきてほしいな。NoSQLまで尖ってないやつ。クエリを発行したら複数のDBから必要データを返す的な。

[hmatsu47]

PostgreSQLでも（クラスタインデックス関係なく）PKがUUIDv4みたいなランダム値だと挿入時の性能ペナルティが生じる点については注意が必要。高頻度挿入するような使い方をしなければあまり気にする必要はないけど。

[kako-jun]

CREATE TRIGGER が3つ並んだ箇所が、封神演義の絵なみに目が滑りました

[hogege]

φ(.. )

[zgmf-x20a]

タグはPostgreSQLなのにPostgres？読みはそうなんだけどね。

[soreso]

すごい（幼並感）

[snowcrush]

自分も強制更新した方がいいに一票。行の最終更新日以外の意味を持たせるならカラムを分けた方がいい。

[syu-m-5151]

“Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス”

[at_yasu]

UUID v7 そんなのできたのか。ほー。

[yuuAn]

MySQL の TIMESTAMP の 2038 年問題なんとかならないのかなあ

[asflash8]

学び

[yarumato]

“idは連番かUUIDか。UUIDのバージョンと型。created_at,updated_atのテーブル定義。MySQLのTIMESTAMP型は2038年で頭打ちになる。MySQLのupdated_atは更新された場合のみ自動で埋めることが可能。Postgresはトリガーが3つも必要”

[codehex]

恥ずかしながら ON UPDATE 知らなかった