履歴を持つデータの設計

Transcript

1. 1.

   履歴を持つデータの設計 kawasima 酔いどれ設計ナイト2019

2. 2.

   課題 • 適用開始日 • 変更履歴 • 削除フラグ • …

3. 3.

   ありがちなアドバイス • 最新のものだけ残して、あとはKVSに 入れろ • フラグじゃなくてステータスにしろ • ビュー (マテビュー)でなんとかしろ •

   …
4. 4.

   業務を考えずにパターンは決まらない イミュータブルデータモデルに沿って、まずは エンティティを分類 会員ID 姓 名 郵便番号 住所 電話番号 注文ID

   会員ID 注文日時 リソース イベント 会員 注文 https://www.slideshare.net/kawasima/ss-40471672
5. 5.

   イベントとリソースそれぞれで、 「履歴」について考えてみます

6. 6.

   イベントの履歴 イベントはそもそも履歴だ。

7. 7.

   リソースの変更イベント リソースエンティティに更新日時をもたせたくなるのは、リソー スにまつわるイベントが洗い出せていないことが原因です。 会員ID 姓 名 郵便番号 住所 電話番号 更新日時

   会員 • 会員が自分自身で会員情報変更ペー ジから変更する • 規約に違反した会員であったため、 お客さまセンターのオペレータが強 制退会をおこなう。 • 会員からの「誤った退会をしてし まったので取り消して欲しい」との 問合せを受けて、お客さまセンター のオペレータが会員の復会をおこな う。
8. 8.

   業務に沿ってイベントを設計する 会員ID 姓 名 郵便番号 住所 電話番号 会員 会員変更ID 会員ID

   姓 名 郵便番号 住所 電話番号 変更日時 会員変更 強制退会ID 会員ID 強制退会日時 強制退会理由 強制退会 復会ID 会員変更ID 復会日時 復会
9. 9.

   子リソースをたくさんもつリソースの 変更イベント 全部のエンティティ分、変更履歴テーブルもつの?

10. 10.

    こういうリソースの変更履歴用途 • カスタマ問い合わせ対応 • 変更トリガーでのストリーム処理 (検索インデックス作成など ) • 属性での複雑な検索はいらない •

    時系列DBやドキュメントデータベースに 突っ込む
11. 11.

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

12. 12.

    None
13. 13.

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

14. 14.

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

15. 15.

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

16. 16.

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

17. 17.

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

18. 18.

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