はじめに
こんにちは、鬼塚と申します。
営業職として働きながら、現在はSiiDというAIプログラミングスクールにて、エンジニアになるべくソフトウェア開発や生成AIを用いた開発手法について日々学習しています。
今回は現在企画中のポートフォリオについて、ER図を作ったのでそれについてまとめてみます。
アプリケーションの概要
サバゲー（サバイバルゲーム）をする人が、1ゲームごとの戦績を記録できるWebアプリです。
- フィールドの休憩時間に、その日のゲームのキル数・デス数・勝敗をスマホで数タップで記録できます
- 記録した戦績から、通算のK/D比やその推移をグラフで確認でき、自分が上手くなっているかを数字で見られます
- 全国のサバゲーフィールドの情報と7日分の天気予報を見られるので、次にどのフィールドへ行くかを決める手助けになります
私自身サバゲー歴は10年ほどありますが、自分が上手くなっているのかは感覚でしか分かりませんでした。ゲームが終わったあとに「今日は何キル取れたっけ」と思い出そうとしても、もう覚えていません。FPSのゲームの戦績画面のように、サバゲーでもキルデス比を残しておきたいと思ったのが、このアプリを作ろうと思ったきっかけです。
ER図
drawSQL：https://drawsql.app/teams/shogo-onizuka/diagrams/d8bdfae2
テーブルは次の6つです。
| テーブル | 中身 |
|---|---|
| users | 利用者（管理者も同じテーブル） |
| fields | サバゲーフィールドの情報 |
| field_sources | フィールド情報の取得元（どこから・いつ集めたか） |
| battle_days | 1日ぶんの記録（日付・フィールド・その日のコメント） |
| games | 1ゲームの記録（前半・後半それぞれのキル数・デス数・勝敗） |
| inquiries | お問い合わせ |
工夫した点
1. 「1日ぶんの記録」と「1ゲームの記録」を分けた
サバゲーは1日に何ゲームも行いますが、日付とフィールドはその日のあいだ変わりません。そこで、日付・フィールド・その日のコメントは battle_days に、1日・1フィールドにつき1行で持たせ、ゲームごとの数字は games に分けました（同じ人・同じ日・同じフィールドの行は重複できない制約を付けています）。フィールドで入力するときも、日付とフィールドは1日に1回選ぶだけで、2ゲーム目からはキル数・デス数・勝敗だけで追加できます。
2. 前半・後半の勝敗を、それぞれ4択で残せるようにした
サバゲーは前半と後半で攻守が入れ替わる別の勝負なので、勝敗をそれぞれ記録します。勝ち／負け／引き分けに加えて「不明」を選べるようにし、覚えていなくても記録をあきらめずに済むようにしました。
3. フィールドは削除せず、公開／非公開で切り替える
戦績から参照されているフィールドは、外部キー制約があるため削除できません（無理に消せば、そのフィールドの戦績も一緒に消すことになります）。そこで fields に is_published を持たせ、削除の代わりに非公開にする形にしました。AIで集めたフィールド情報を、運営者が確認するまで非公開にしておく使い方もできます。
4. データの出どころの記録を別のテーブルに分けた
フィールドの最初のデータはAIで集めるため、間違いを後から追えるように「取得元のURL」と「取得した日」を残します。この2つはフィールドそのものの情報ではなく「データをどこから、いつ集めたか」の記録なので、field_sources テーブルに分けました。管理画面では取得元を任意入力とし、入力がないフィールドには field_sources の行を作りません。結果として、fields はフィールドそのものの情報だけになりました。
5. 管理者を別のテーブルにせず、users に印を1つ持たせた
管理者は運営者の1人だけなので、管理者用のテーブルは作らず、users に is_admin を1つ持たせました。ログイン画面も一般の利用者と共通にでき、テーブルの数を増やさずに済みます。ゲストログインも、共用のゲスト用ユーザーを1人用意して使うので、テーブルやカラムは増やしていません。
6. 入る値をデータベースの側で決めておいた
勝敗（勝ち／負け／引き分け／不明）、お問い合わせの種別と対応状況、屋内／屋外／両方は、決めた値しか入らないようにしました。キル数とデス数も0以上しか入りません。駐車場と送迎は、公式サイトに書いていないことがあるため、空欄を「不明」として扱えるようにしています。画面側のチェックが漏れても、おかしなデータが保存されないようにするためです。