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