[TIL]タイムライン管理&線分タイムライン

ブランデーでモデリングを行う場合は、次の状況に適しています.

製品表には、「価格」、「割引率」、「割引開始日」および「割引終了日」が含まれています.

表の情報を変更した場合、その商品の価格は後でわかりません.

割引と価格に関する内容を履歴として残す必要があります
こんな状況で初めて思いましたが、

「価格履歴」テーブルを作成し、価格を変更するたびに変更日と変更価格を追加します.

「割引履歴」表を作成し、割引/割引開始日/割引終了日を変更するたびに履歴

を作成します.
しかし、このようにすると、過去のある日の価格を知るために、価格と割引率を同時に確認する必要があるというトラブルがあったので、組長に相談して、2つのテーブルを合わせてもらいました.
2つのテーブルを合わせて、とても奇妙なテーブルが現れて、組長はあなたに「線人履歴」を使ったかどうかを聞いたので、線人履歴を調べました.
履歴管理
多くのコラムを持つ「商品」表があると言うと、商品表の1つの情報が変化すれば、「スクリーンショット」のように商品のすべての情報を保存することができ、価格や割引だけでなく、商品名、商品説明などすべての情報を保存することができます.
実際のサービスは提供していないため、コア情報:価格&割引情報のみを格納することにしました.
1.ポイント履歴
情報が変更されると、次の2つの情報だけが保存され、後で変更する必要はありません.

スクリーンショット日

スクリーンショット内容

id | price | changed_at      
1  | 10000 | 2020.10.25         
2  | 15000 | 2020.10.27         

このような日付は蓄積にすぎない.
 
2.線分履歴
ポイント履歴とは異なり、より多くの情報を追加します.

スクリーンショット日

スクリーンショット内容

スクリーンショットの有効期間はいつですか?
例えば、今日から10000円で販売することを決めたら、

開始日:2020.10.25

価格:10000

終了日:99999.12.31

このように保存し、再び情報を追加するシャットダウン日を新しいrowの開始日に変更します.

id | price | validate_from      | validate_until
1  | 10000 | 2020.10.25         | 9999.12.31

上の表が10/27に新しい修正があれば、

id | price | validate_from      | validate_until
1  | 10000 | 2020.10.25         | 2020.10.27
2  | 15000 | 2020.10.27         | 9999.12.31

これで最初の行のvalidate untillが変更されます.
 
本来多くの情報は,ユーザ情報の変化,商品情報の修正,保存が必要であったが,時間的な関係から,最も重要な価格/割引に関する内容のみを入れて線分履歴管理することにした.
逆に、比較的削除しやすいオプション情報は、削除履歴を管理する必要はなく、soft delete Columnを追加します.
1週間かけてプロジェクトの論理と計画を把握した.来週からコードに移行するのではないかと心配していますが、すべての機能を実現する考えを捨てて、できるだけ最善を尽くします.
来週も無事に過ごせるように