履歴を持つデータの設計

酔いどれ設計ナイト2019の発表資料です。

1. 履歴を持つデータの設計 kawasima 酔いどれ設計ナイト2019
2. 課題 • 適用開始日 • 変更履歴 • 削除フラグ • …
3. ありがちなアドバイス • 最新のものだけ残して、あとはKVSに 入れろ • フラグじゃなくてステータスにしろ • ビュー (マテビュー)でなんとかしろ • …
4. 業務を考えずにパターンは決まらない イミュータブルデータモデルに沿って、まずは エンティティを分類 会員ID 姓 名 郵便番号 住所 電話番号 注文ID 会員ID 注文日時 リソース イベント 会員 注文 https://www.slideshare.net/kawasima/ss-40471672
5. イベントとリソースそれぞれで、 「履歴」について考えてみます
6. イベントの履歴 イベントはそもそも履歴だ。
7. リソースの変更イベント リソースエンティティに更新日時をもたせたくなるのは、リソー スにまつわるイベントが洗い出せていないことが原因です。 会員ID 姓 名 郵便番号 住所 電話番号 更新日時 会員 • 会員が自分自身で会員情報変更ペー ジから変更する • 規約に違反した会員であったため、 お客さまセンターのオペレータが強 制退会をおこなう。 • 会員からの「誤った退会をしてし まったので取り消して欲しい」との 問合せを受けて、お客さまセンター のオペレータが会員の復会をおこな う。
8. 業務に沿ってイベントを設計する 会員ID 姓 名 郵便番号 住所 電話番号 会員 会員変更ID 会員ID 姓 名 郵便番号 住所 電話番号 変更日時 会員変更 強制退会ID 会員ID 強制退会日時 強制退会理由 強制退会 復会ID 会員変更ID 復会日時 復会
9. 子リソースをたくさんもつリソースの 変更イベント 全部のエンティティ分、変更履歴テーブルもつの?
10. こういうリソースの変更履歴用途 • カスタマ問い合わせ対応 • 変更トリガーでのストリーム処理 (検索インデックス作成など ) • 属性での複雑な検索はいらない • 時系列DBやドキュメントデータベースに 突っ込む
11. ロングタームイベントパターン • イベントでもステータス管理が必要なケース • 長期間で完結するイベントはステータスをもち ステータス遷移のイベントを詳細イベントとし て記録する
13. リソースの履歴 • 買ったときの商品価格を参照したい。 • 駅テーブルに2020年〜高輪ゲートウェイが追 加される。 などなど →「履歴」というよりは「世代」になる。
14. デメリット大きいので、適用することは少ない。 が、マスタ管理機能など入力のみのものであれば用いる ことあるかな…
15. 過去と予定を分けて扱えれば シングル世代テーブルパターンでもOK
16. バックエンド業務では世代が 必要で、コンシューマ向けの 機能では最新のもののみがあ ればよい、というパターンで は活用できる。
17. Gitのバージョンとタグの関係性のイメージ 古い世代や未来の世代も画一的に扱う業務に おいては、このパターンを用いる。
18. まとめ 「履歴」というワードで思考停止して、 実装手段の話を始めてはいけない 業務での利用用途を突き詰めて考え、 イミュータブルデータを出来るだけ作るように がんばりましょう。