Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
履歴を持つデータの設計
Search
Yoshitaka Kawashima
April 12, 2019
Programming
58
25k
履歴を持つデータの設計
酔いどれ設計ナイト2019の発表資料です。
Yoshitaka Kawashima
April 12, 2019
Tweet
Share
Other Decks in Programming
See All in Programming
Node.js, Deno, Bun 最新動向とその所感について
yosuke_furukawa
PRO
6
3k
Go1.24で testing.B.Loopが爆誕
kuro_kurorrr
0
160
体得しよう!RSA暗号の原理と解読
laysakura
3
530
自分のために作ったアプリが、グローバルに使われるまで / Indie App Development Lunch LT
pixyzehn
1
120
AIエージェントを活用したアプリ開発手法の模索
kumamotone
1
750
2025/3/18 サービスの成長で生じる幅広いパフォーマンスの問題を、 AIで手軽に解決する
shirahama_x
0
160
データベースエンジニアの仕事を楽にする。PgAssistantの紹介
nnaka2992
9
4.2k
MCP世界への招待: AIエンジニアが創る次世代エージェント連携の世界
gunta
2
570
PHPでお金を扱う時、終わりのない 謎の1円調査の旅にでなくて済む方法
nakka
3
1.2k
PsySHから紐解くREPLの仕組み
muno92
PRO
1
520
eBPF Updates (March 2025)
kentatada
0
130
マルチアカウント環境での、そこまでがんばらない RI/SP 運用設計
wa6sn
0
580
Featured
See All Featured
Producing Creativity
orderedlist
PRO
344
40k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.6k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
8
700
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Thoughts on Productivity
jonyablonski
69
4.5k
Six Lessons from altMBA
skipperchong
27
3.7k
KATA
mclloyd
29
14k
Transcript
履歴を持つデータの設計 kawasima 酔いどれ設計ナイト2019
課題 • 適用開始日 • 変更履歴 • 削除フラグ • …
ありがちなアドバイス • 最新のものだけ残して、あとはKVSに 入れろ • フラグじゃなくてステータスにしろ • ビュー (マテビュー)でなんとかしろ •
…
業務を考えずにパターンは決まらない イミュータブルデータモデルに沿って、まずは エンティティを分類 会員ID 姓 名 郵便番号 住所 電話番号 注文ID
会員ID 注文日時 リソース イベント 会員 注文 https://www.slideshare.net/kawasima/ss-40471672
イベントとリソースそれぞれで、 「履歴」について考えてみます
イベントの履歴 イベントはそもそも履歴だ。
リソースの変更イベント リソースエンティティに更新日時をもたせたくなるのは、リソー スにまつわるイベントが洗い出せていないことが原因です。 会員ID 姓 名 郵便番号 住所 電話番号 更新日時
会員 • 会員が自分自身で会員情報変更ペー ジから変更する • 規約に違反した会員であったため、 お客さまセンターのオペレータが強 制退会をおこなう。 • 会員からの「誤った退会をしてし まったので取り消して欲しい」との 問合せを受けて、お客さまセンター のオペレータが会員の復会をおこな う。
業務に沿ってイベントを設計する 会員ID 姓 名 郵便番号 住所 電話番号 会員 会員変更ID 会員ID
姓 名 郵便番号 住所 電話番号 変更日時 会員変更 強制退会ID 会員ID 強制退会日時 強制退会理由 強制退会 復会ID 会員変更ID 復会日時 復会
子リソースをたくさんもつリソースの 変更イベント 全部のエンティティ分、変更履歴テーブルもつの?
こういうリソースの変更履歴用途 • カスタマ問い合わせ対応 • 変更トリガーでのストリーム処理 (検索インデックス作成など ) • 属性での複雑な検索はいらない •
時系列DBやドキュメントデータベースに 突っ込む
ロングタームイベントパターン • イベントでもステータス管理が必要なケース • 長期間で完結するイベントはステータスをもち ステータス遷移のイベントを詳細イベントとし て記録する
None
リソースの履歴 • 買ったときの商品価格を参照したい。 • 駅テーブルに2020年〜高輪ゲートウェイが追 加される。 などなど →「履歴」というよりは「世代」になる。
デメリット大きいので、適用することは少ない。 が、マスタ管理機能など入力のみのものであれば用いる ことあるかな…
過去と予定を分けて扱えれば シングル世代テーブルパターンでもOK
バックエンド業務では世代が 必要で、コンシューマ向けの 機能では最新のもののみがあ ればよい、というパターンで は活用できる。
Gitのバージョンとタグの関係性のイメージ 古い世代や未来の世代も画一的に扱う業務に おいては、このパターンを用いる。
まとめ 「履歴」というワードで思考停止して、 実装手段の話を始めてはいけない 業務での利用用途を突き詰めて考え、 イミュータブルデータを出来るだけ作るように がんばりましょう。