履歴を持つデータの設計

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

[diffie]

意識低い系なので、注文履歴には注文成立時の価格 (商品名とかも) をコピーしたい派。/というかまとめ買いとか会員種別割引とかあるから、履歴に持たないとダメだと思う。BIとかに流すときに毎回再計算できんでしょ

[pro_shunsuke]

現実世界のものをデータモデルに落とし込むのって難しいんだよね。いくつかパターンはあるけどピッタリ当てはまる場合ばかりじゃないから、業務をしっかり理解してイベントとリソースに分けていくことが大事だ

[hamlet-r]

まとめのページの内容が全てだなと思った。確かにその通り、実装を急いではいけない。

[shogo_okamoto]

そもそも、この複雑さは本当に必要なのか?

[chimerast]

履歴情報を柔軟に表現できるDBを今作ってるけど、RDBをRDBとして使うと表現できないというのが、色々調べたり考えた末の結論だった。どこかで発表しよう。SQL使ってメンテナンスができないのが重大な欠点なんだけど。

[marisatokinoko]

これ難しいんだよなー、いまだよくわからん

[masatomo-m]

良いまとめだ。履歴情報の利用用途によってはそもそもRDBに保存するのが良いのかというケースもあったりするので、どういう使い方をするのかをよく考えないといけないのよね

[shozzy]

ワークフローを設計したとき履歴を持たせすぎて、運用開始後1年ほどしてパフォーマンス問題が起きたなぁ(遠い目)。履歴はあったら便利だけど常に必要なデータではないので、うまく切り出しておく必要があると学んだ。

[n314]

逆だなあ。RDBはイミュータブルなデータをなるべく持たないようにしたい。PK、UK、FKやCHECK制約でデータの矛盾を排除したいので。入会アクティビティログに矛盾したデータが入ってるとかアプリで管理したくない。

[kiwi0120]

履歴データの保持って難しい。ビッグデータ時代だからあれもこれも復元可能な形で持つ設計にするとｎのｎ乗が爆発する。じゃあそこからnを厳選すると、となっていつも最小限のログに帰結する。

[uesima]

データベース

[kiririmode]

イミュータブルデータモデルと履歴管理、世代管理を組み合わせた時の観点が言語化されている

[mizdra]

良い

[tmatsuu]

わかる。とてもむずかしい。予約機能を含む履歴実装で疲弊して職業プログラマーを引退した

[tgk]

「会員変更イベント」テーブルが会員マスタの履歴テーブルそのものになっている。「リソースごとに履歴テーブルを持たざるを得ない(が、あえて履歴テーブルとは呼ばない)」という主張だと思えばいいのかな

[rryu]

請求履歴や注文履歴などはスナップショットを取るイメージで作らないと顧客マスタの会社名や住所が変わって残念な思いをするという。

[t-murachi]

履歴と最新データを分けて持つってのはセオリーっちゃセオリーだ罠。パフォーマンスだけ気になるなら日付キーのソート順を逆にしておくとか最新フラグを設けちゃうとかって手はあるｗ

[nilab]

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

[iTaro]

履歴に関しては、テンポラルデータモデルを試してみたりもしたけれど、いつも用は足りるが、どこか物足りないという微妙なしこりが残る部分だったりする。厄介だよね

[airj12]

標準で有効期間を含めたユニーク制約をつけられて条件に日時を指定できるDBMSが欲しい

[Shinwiki]

こういうの

[K-Ono]

スーパーの野菜とか毎日値段が違うんだけどこういうのどうすりゃいいんだろうな。しかもインストアJANだし。

[Agrius_Akita]

あんま関係ないけど、注文明細には数量と価格の両方を持ちたいと思うなどした　　（同じ商品でも入口や販売数、取引先などなどで特別価格に変わる事はよくある）

[karikari1255]

いいまとめ。amazonはカート商品の価格改定or最安出品者の変更があると通知出すけどカート入れた時にスナップショット持ってんのかな

[ka-ka_xyz]

いみゅーたぶるでーたがいっぱいだよう...もうたべられない（もういや）

[masatotoro]

履歴の考え方

[wata88]

めちゃめちゃ良い

[d415uk3]

アナパナだな

[daaaaaai]

よい。16ページ、注文明細に当時の価格をスナップショット的に持つのがECなんかでは多いのかなー