履歴テーブルから最新の1件を取ってくる方法 - そーだいなるらくがき帳

例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First

[turanukimaru]

履歴テーブルを使ったりイベント駆動にして集計したりすると update が要らなくなるのだが latest に頻繁にアクセスするなら結局 latest テーブルを作ってしまったほうがシンプルになるんだよな。

[kamm]

『そこで対策としてはlatestテーブル、つまり計算結果のcacheを作る。これは本当に 最終手段 であることを覚えておいてほしい』最終手段かなあ・・？

[dagama]

user_idごとにMAX(created_at)したやつをjoinしてcreated_at=MAX(created_at)でよくない？／最終手段って書いてるけど参照頻度が多いならlatestマテビューは普通に検討していいと思う

[pixmap]

latestはDB上のテーブルとして作るんじゃなくて、Memcache上に置いとくのがいいと思うんだけどな。ビジネスロジックに必要最低限な情報と一緒に。

[Songmu]

これ良く困るやつなので良いまとめ。僕は基本的にはインデックス効きづらいクエリを投げることをしたくないし、余計なインデックスも増やしたくないので、latestテーブルを作っちゃうな

[xsde]

インフラエンジニアから見るとむしろテーブルスキャンの方を最終手段としてほしいところ。

[paradoxparanoic]

historyのpkどうなってるんだ？そういうテーブル設計お父さん嫌いだな

[youko03]

履歴はNoSQLにためておく、latestテーブルはRDBで作る、という方針でだいたいカバーできたりしないんだろうか。

[odz]

普通にfirst_valueかlast_valueじゃダメなんかな。

[k-holy]

いまだに脳がSQL92で止まってる上に長らくMySQLばかりだったので、Window関数全然使いこなせてない…。DISTINCT ONめちゃ便利そう。新規案件はPostgreSQLにしよ…。

[tmatsuu]

わいわい。ISUCON14でlatestの作成にトリガー戦略をとった結果「これが正義では」と思った。ただBEFORE/AFTERのタイミングをきちんと考えて実装しないとデッドロックで後から死にそうになるので気をつけろよ、という認識

[kiririmode]

履歴の扱い方

[shigeaki1jp]

“MySQL”

[nekoruri]

DISTINCT ONめちゃくちゃ人類が欲しかったやつじゃん

[sonots]

良いまとめ

[izoc]

Window関数昔からあるのに知らんかったわ…サブクエリとかgroupby駆使して書いてた

[tacamula]

業務用、決済系などはこうしたいよね。WriteヘビーだからLatestテーブルは必要性が後になりやすく、その書き込みは別トランザクションにしたいのも理解。

[snowcrush]

こういうのがあるからPostgreSQL推奨派です

[jintrick]

"基本的にはWindow関数を使えばよく、SQL自体はChatGPTなどにDDLを覚えさせて、質問すれば教えてくれる。 PostgreSQLユーザはDISTINCT ONを覚えておくとちょっとした時に助かることがある。"

[versatile]

ユーザーの数だけ table を作るのはどう？。一見アホな案だが、1000万ユーザーいるとして table が 1000万か・・・。InnoDB では最大 40 億個の table をつくれる。そこまでやるなら nosql 使え、になるか？誰かやってみない？

[strawberryhunter]

「テーブルスキャン1回で済む」使ったことが無いので知らないけど、インデックスが効かなくて全レコード読み出すってことだとすると全然解決にならない。結局、最新のIDを保持するテーブルだな。

[shimarisugi]

まず何より先にlatestを作って古いデータを残すためのhistory(latestのupdateの際に古いのを移動させる)を作るかなぁ。履歴の用途にもよるけど。

[nakag0711]

user_id, max(created_at) GROUP BY 1だと主キーのidが取れないという昔のSQLの問題が窓関数で解決。とは言えクエリプランがマトモなものになるのかビクビクしながら使っている感

[onesplat]

◯◯ごとに(最新|最大|最小)のn件を取ってくる方法ってことね。タイトル読んで何が難しいのか意味不だったわ。

[aox]

そんなややこしいことをしなくても電話一本入れれば済む話では…

[bopperjp]

履歴テーブルの取り扱い

[HHR]

historyテーブルが巨大化することを想定している時点で、RDBMS諦めてユーザ毎の最新の取得は別システムにしたいな。取得に加えてupsert の様なトランザクショナルな要件だとしたら辛い戦い。ロックとの戯れに興じる

[hagane]

イミュータブルデータモデルだと必須のやつという認識(言葉しか知らない)

[Kazumi007]

Postgresqlなら、DISTINCT ON

[theatrical]

postgresqlじゃなかったmax_byでよさそう。

[razihai]

work的にlatest作っちゃうのが一番よね(まぁ用途次第なのでなんともだが)

[mcddx30]

https://x.com/songmu/status/1866366671298113944

[hryord]

履歴の頻度によると思うけどlatest用の番号かフラグじゃあかんのか

[yutakaan02]

oracleだとnot exists が定番だけど、PostgreSQLにはないんだっけ？

[hdampty7]

MySQLのバージョンが古くてWindow関数使えない場合のあの多段GROUPBY文が基本形かな。履歴を集計する（中央値や平均や偏差など）場合はテーブル作って保存するのが基本。latest_historyはその一種に思える。

[crosscrow]

毎回悩むやつ。ありがたや。