データベース構造の見直し

 現在進めているデータベース設計はもう1年以上前からなんですが、当初から問題はあったんですが、先に進める為に特に手を加えずにいました。フルセットアップ(1986年辺りからなのかな)で登録内容をステータスバーに表示させる為に処理毎にApplication.DoEvent()を呼び出しているので１４時間程度掛かる処理で出来上がるデータベースファイルは５７ギガバイトとかの巨大なものです。これを最適化する処理は３時間弱とかだった。

先週ふとオッズ関連の作業してて、今のまま進めるのは得策じゃないと判断し、オッズ及び票数のテーブル設計を変更する事にした。これまでは開発当初利用してたコードファーストでのデータベース作成の名残で親子関係を持つテーブル構成で設計してたんですが、これがデータベースへの登録処理で大きな負担になっている事は分かっていました。更にこの親子関連のデータ項目保持の為にデータベースファイルが肥大化してるんだとの認識もしてました。
親テーブルに基本情報を持ち、子テーブルに個々の目のデータを入れる設計なので、単勝だとまあ最大１８頭分のデータが子テーブルに入るんですが、三連単に至っては最大4,896個ものデータがレース毎に入る訳でこの可変なデータを１つのテーブルに収めるのが良いのか悪いのかが、データベースファイルとして基本的な事を理解してると思い判断してたんですがsqlite3を信じて決断(笑)。3日程度掛かる変更作業を夜勤明けにこなして週末のレースには挑める様に終わらせました。まあ、日曜日のレースはWIN5の1レース目の予想中に気を失って気が付いたのは夕方の全レース終了後orz まあ、フェブラリーステークスも1番人気→3番人気→4番人気の固い決着だし、WIN5も5万円台の決着なんで、当然そんな固い予想はしないので結果オーライでした😁

修正後の高速セットアップ(Application.DoEventの呼び出しは最小限に抑える)では今まで2時間程度だったのが1時間40分で済みました。出来上がったデータベースファイルは１２ギガバイト程度までダイエットが出来、最適化に要する時間が７分弱とか!　色々な動作が機敏になる副作用があり、手間暇かけたかいがありました。今後はこのバージョンで開発進める事に。