MySQLデータベーススキーマが電車の時刻表でどのように見えるかに興味があります。
通常、これは最終的な結果として表形式で表示されます。
Train No. 11111 22222 11111
Train Day Mo-Fr Sat Sun
Station A d 06.00 07.00 07.00
Station B d 06.10 07.10
Station C d 06.20 07.15
Station D a 06.30 07.40
Station D d 06.35 07.25
Station E d 06.45 07.45
したがって、各列車には列車番号がありますが、月曜日から金曜日まで土曜日と日曜日で番号が重複するため、一意ではありません。次に、電車はいくつかの駅で止まりますが、すべてではありません。駅には到着(a)時刻と出発(d)時刻、またはどちらか一方が必要な場合があります。
駅は距離によって注文できます。
これまでのところ、次のテーブルが必要だと思っています。
これで十分ですか?
特定のスケジュールが実際に実行されるすべての日を明示的に保存することを強く検討します。これにより、次のような構造が得られます。
そうすることで、「10月1日にX駅に向かう列車は何ですか?」などの質問に簡単に答えることができます。また、電車が運行していないとき(クリスマスの日など)に「一時的なギャップ」を特定することもできます。 1回限りの列車は、SCHEDULE_DAYSにエントリが1つしかない単純な列車になりました。
週末と平日のスケジュールは異なる可能性があるため、日ごとに行を分ける方が良いと思います。これにより、必要に応じて、曜日ごとに異なるスケジュールをリンクできます。
最初の実行と終了(最初の日付が実行されなくなった)の日付フィールドを持つことで、1回限りの実行を処理できます。これにより、スケジュールの変更を処理することもできます。初回実行日が主キーの一部になります。このテーブルで、リレーションシップテーブルの代理主キーが必要になる場合があります。
曜日を7つの個別のインジケータフィールドに分割することを検討します。これにより、特定の曜日にのみ実行されるスケジュールを柔軟に処理できます。駅と駅の関係は、(電車、駅、タイプ(到着/出発)時間帯)に削減できます。ノートは、密度に応じて別の関係に入る可能性があります。