1

MYSQLで列車の時刻表データベースを作成しました。毎日数千のルートがあります。ただし、いくつかの例外を除いて、ほとんどのルートはすべての営業日で類似していますが、週末では異なります。

この時点で、私は基本的に毎日深夜にSQLテーブルを更新して、次の24時間の出発を取得します。ただし、これは非常に不便です。したがって、テーブルに日付を保存する方法が必要なので、毎日これを行う必要はありません。

各ルート番号の日付を保存する個別のテーブルを作成しようとしましたが（ルート番号は毎日リセットされます）、クエリが非常に遅くなり、使用できなくなりました。これは、出発時刻と到着時刻を日時として保存する必要があることを意味しますか？その場合、ルートを含むメインテーブルには数百万のエントリがあります。

または別の方法はありますか？

私のルーティングテーブルは次のようになります。

StnCode（別のステーションテーブルで参照）  
DepTime  
ArrTime  
ルート番号  
legNumber
4

2 に答える 2

1

日付はどのように保存しましたか？単一の日付/時刻フィールド？これは確かに最もコンパクトな表現ですが、特に次のタイプのクエリを実行している場合は、インデックス作成とスキャンが最も困難です。

SELECT ...
WHERE MONTH(DepTime) = 4 AND DAY(DepTime) = 19;

このような構成では、各日付フィールドを分解して月/日を抽出するために全表スキャンが必要になります。このような場合は、少し名前を外して、日時を別々の年/月/日/時/分のフィールドに分割し、それらにインデックスを配置することをお勧めします。維持するのは少し面倒ですが、特定の時間部分によるクエリを大幅に高速化することにもなります。

于 2010-04-19T22:03:06.367 に答える
0

  1. スケジュールを日付で保存する代わりに、日 (日、月、火など) に対して保存できます。これにより、ルートの日付を保存する必要がなくなります。ルートはあらかじめ決められたものとして扱うことができるため、ルートは固定されています。列車の数は約 8000 (旅客列車) で、日数は固定 (7) であるため、ルートは (50-1000) であり、各テーブルは、1、1A、鉄道の本で公開されているように、
    これにより列車の膨大な組み合わせを保存することを回避できます。すべての日付が平日の 1 つに変換され、欠落しているデータがないため、db にスケジュールされます。

  2. 最大 7 日間の日数を格納するためのテーブルを作成できます。

  3. 各ステーションがステーションIDではなくタッチポイントになるように、データベースをモデル化することをお勧めします....

  4. また、デザインにハブのコンセプトを導入して、同じ都市の 3 ～ 4 駅を特定することもできます。

  5. 各駅はタッチポイントであり、搭乗ポイント、HALT POINT などの施設によってサポートされています...

  6. 原因は、すべての駅がすべての列車の乗り場であるとは限らない..

  7. 施設は、さまざまな駅で利用できるものです...

  8. すべての列車がすべての設備を利用できるわけではありません...例: Kazipet は駅であり、分岐点でもあります...しかし、少数の列車の場合、少数のルートで、駅を通過し、駅にも停車します。 、しかし、それは駅で新しい乗客が乗ることを許可しません. しかし、それは逆のルートでも同じことを可能にします...

于 2011-02-14T21:36:22.597 に答える