[Day 2: B-15] 操作履歴/時点指定アクセスの実現 - BiTemporal Data Model の実践


yhirano55
yhirano55 commented 4 months

登壇者: 株式会社SmartHR f440

データはWebアプリケーションの中心であり、最も重要なものです。私の勤めるSmartHRでも、人事情報を軸とするWebサービスを展開する事業者として最大限の注意を払って運用を行っています。

データは活動によって刻々と変わっていくものですが、通常のWebアプリケーションでは最新の情報しか表現できていません。そのため、いつ・どのような変更を加えたのかを知りたい、あるいはある時点の情報にアクセスしたいといった要望には応えることができませんでした。SmartHRでは入退社や被扶養者の追加など多様なライフイベントに応じてデータの変更が発生するため、その変遷も表現したいというニーズがかねてよりありました。

この問題を解決するために、私達はBiTemporal Data Modelというデータ構造を導入しています。これにより、時間を指定したアクセスや変更の変遷なども表現できるようになりました。

本セッションではBiTemporal Data Modelとはなにかといった基本的なことから、実戦投入してみて気づいた点、苦労話などを話します。


  • このセッションに関する質問を募集中です
  • 事前に聞きたいことがあれば、何でも書き込んでください。
  • 質問への回答はお約束できません。あらかじめご了承ください

Like(0)

Questions and feedbacks (5)

f440
f440 commented 4 months

@kirikak2

今のところ特にルールなどは決めておらず、エンジニアの個人の判断で検索項目やソートフィールドに応じて適宜追加くらいで済んでいます。

すごくざっくりしたイメージだと「テナント数 x 従業員数 x 履歴」みたいな感じでレコードが増えていくのですが、このうち「テナント」はもともとシャーディングされてて(参考: https://builderscon.io/tokyo/2018/session/5485dc21-810e-4d12-9102-30b2812cd64f ) 、履歴の数もそんなに大量には増えていかないので、今のところは従業員のIDさえインデックスに乗っていれば大きな問題にならないんですよね。あとは要件にあわせてって感じです。 (もちろん削除フラグや有効期間の部分にもインデックスを付けてはいます)

Like(1)

f440
f440 commented 4 months

@cobafan

データ不整合、つらいですよね……アプリ側でどんなに注意して実装してもすり抜ける可能性はあるので、可能な限りデータベースの制約で原則発生できない状況作るしかないと思っています。

Like(0)

kirikak2
kirikak2 commented 4 months

作られるテーブルや検索されるデータによってはIndexの作り方に悩むシーンが多々あるんじゃないかと思うのですが、開発チーム内で統一されたルールとかはありますか?

Like(0)

ujihisa
ujihisa commented 4 months

~Bi-Temporal Data Modelのつらみについて、実際に体験した具体例を聞きたいです!~

ユニーク制約・primary keyの話があったので解決

Like(1)

cobafan
cobafan commented 4 months

「時間によって変わっていくデータ」をDBで管理する際に、 Railsのバリデーションをすり抜けてデータが重複することはありますか? もしありましたらどういう工夫をされてますでしょうか。

Like(0)

Create Comment

Please sign in to comment.

Sign in with GitHub
This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano