Upgrade to Pro — share decks privately, control downloads, hide ads and more …

履歴を持つデータの設計

 履歴を持つデータの設計

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

4effe910c3ff51c0f9091842e3b461f8?s=128

Yoshitaka Kawashima

April 12, 2019
Tweet

Transcript

  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. ロングタームイベントパターン • イベントでもステータス管理が必要なケース • 長期間で完結するイベントはステータスをもち ステータス遷移のイベントを詳細イベントとし て記録する

  12. None
  13. リソースの履歴 • 買ったときの商品価格を参照したい。 • 駅テーブルに2020年〜高輪ゲートウェイが追 加される。 などなど →「履歴」というよりは「世代」になる。

  14. デメリット大きいので、適用することは少ない。 が、マスタ管理機能など入力のみのものであれば用いる ことあるかな…

  15. 過去と予定を分けて扱えれば シングル世代テーブルパターンでもOK

  16. バックエンド業務では世代が 必要で、コンシューマ向けの 機能では最新のもののみがあ ればよい、というパターンで は活用できる。

  17. Gitのバージョンとタグの関係性のイメージ 古い世代や未来の世代も画一的に扱う業務に おいては、このパターンを用いる。

  18. まとめ 「履歴」というワードで思考停止して、 実装手段の話を始めてはいけない 業務での利用用途を突き詰めて考え、 イミュータブルデータを出来るだけ作るように がんばりましょう。