スロット攻略 プロジェクトドキュメント

Appearance

機種台数変化バッチ ​

目的 ​

新台入れ替えなどで、同一ホール・同一機種の台数が前日からどう変わったかを保存し、公開画面や管理画面から参照できるようにする。

テーブル定義の正本は custom-tables.dbml の db_daily_article_kishu_count_delta を参照する。この文書には DB スキーマ詳細を書かず、トリガーと処理内容を記載する。

トリガー ​

トリガー実行内容
slot_kouryaku_daily_data_imported台別データのインポート・削除後に対象 hall×日付の台数変化を再計算する
保守用バックフィル CLI必要性が確認できた場合だけ、指定期間の hall×日付を手動再計算する

日次 Cron は機種別サマリを再計算するが、台数変化は更新しない。

処理内容 ​

DailyArticleKishuSingleDaySummaryComputer が、機種別サマリ再計算と同じ流れで台数変化を算出する。

  1. 対象 hall×日付の機種別サマリを再計算する。
  2. 対象日の機種台数と、カレンダー前日の機種台数を比較する。
  3. 対象 hall×日付の台数変化行を全削除する。
  4. 台数に変化がある機種だけを登録する。

前後同数の機種は行を持たない。前日に当該 hall のサマリが存在しない場合は、比較母体が不完全なため台数変化を作らない。

判定ルール ​

状況登録内容
既存機種の増減当日台数 - 前日台数
新台当日台数を正の値で登録
撤去前日台数を負の値で登録
前後同数登録しない
前日ホール欠損登録しない

比較キーは hall と正規化後の機種名キーを使う。機種名の正規化は KishuNormalizer の処理に従う。

整合性ログ ​

再計算後、計算自体は中断せず、必要に応じてログを出す。

reason意味
incomplete_data前日 hall のサマリが存在せず、台数変化を作らない
hall_total_changed当日総台数と前日総台数が異なる
delta_sum_mismatch総台数が不変なのに台数変化合計が 0 ではない
invariant_break台数変化合計が総台数差分と一致しない

管理画面 ​

誤検知の修正用に、管理画面「設定 → 機種台数変化（前日比）」を用意している。

操作内容
一覧hall / period_key / kishu / count_delta を確認する
編集台数変化の値を整数で修正する
削除変化なしに戻したい行や誤検知行を削除する

台別データインポートまたは保守用バックフィル CLI で再計算すると、対象 hall×日付の手動修正は再計算結果で置き換わる。

保守用バックフィル CLI ​

現状、本番で過去期間バックフィルを定常的に実行する前提はない。集計ロジック修正やデータ不整合調査で必要性が確認できた場合だけ、機種別サマリバックフィル CLI を使って対象期間を再計算する。

下流 ​

参照ファイル ​

  • core_src/Service/daily_article_kishu_single_day_summary/DailyArticleKishuSingleDaySummaryComputer.php
  • core_src/Model/Repository/daily_article_kishu_count_delta_repository/DailyArticleKishuCountDeltaRepository.php
  • core_src/Admin/kishu_count_delta/KishuCountDeltaAdminPage.php
  • docs/design/テーブル定義/custom-tables.dbml