履歴テーブルについて - 一休.com Developers Blog

この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの

[naokun776]

履歴テーブルときくとおもいだす https://www.slideshare.net/itohiro73/jjug-ccc-2017-spring-bitemporal-data-modeling-and-reladomo

[daaaaaai]

はい

[el7]

ログテーブル

[fkmy]

良記事

[Soudai]

すげー為になる記事！

[tmatsuu]

先生、予約機能を考慮するともう1パターン生まれそうです。

[RabbitBit]

バージョンテーブルとログテーブルの使い分けは、積極的に使っていきたい。

[braitom]

履歴テーブルのパターンについて。

[manchose]

関連テーブルが多いときどうするのか気になる。paper trail gemとかaudits gemとかみたいにJSONにして関連テーブルごとぶっこむとか。

[nnhrsk]

履歴の永続化パターン

[kei_0000]

例えば価格の変更した時に、その変更履歴を後でわかるように記録する。ただこれは単に日時指定で過去のデータを取り出せるようにする機能がDB側にあればいいんだよなあ。時系列DBとはちょっと別かな。

[castaneai]

こういう話すき

[lizy]

監査とか考えるとイベントを主にしたイベントソーシング＋参照用DB/テーブルがいいんだろうか

[tatsu_tora]

履歴とログは別物だと思うのだが... 履歴 -> ユーザの購入履歴等、ログ -> アクセスログ等、貯めるという意味では近しいものはあるけど、役割としては違うかなと

[shiba-yan]

ワイなら Event Sourcing と Materialized View を組み合わせるかな