0

私は、日付範囲と日付範囲に属するいくつかの値を持つレコードである約10のテーブルが好きです。

各テーブルにはいくつかの意味があります。

例えば

料金

    start_date DATE
    end_date DATE
    price DOUBLE

可用性

    start_date DATE
    end_date DATE 
    availability INT

次にテーブルの日付

     day DATE

2年先の毎日の日付はどこにありますか。

最終結果は、これらの10個のテーブルを日付テーブルに結合することです。他にもいくつかの結合とサブクエリがあるため、クエリには少し時間がかかります。

私は毎日10個のテーブルデータすべてを含む1つの大きなテーブルを作成することを考えていましたが、最終的なテーブルには約150万から200万のレコードが含まれます。

テストから、テーブルを結合して結合された結果を検索する代わりに、このテーブルを検索する方が速いようです（約1秒ではなく0.2秒）。

そんなに多くのレコードを持つテーブルを持つことが悪い考えであるはずの本当の理由はありますか？

ファイナルテーブルは次のようになります

    day DATE 
    price DOUBLE 
    availability INT

コメントしてくださってありがとうございます。

4

2 に答える 2

0

私は一度この道を下りて後悔しました。

数百万行の予測があるという事実は、あるテーブルの日付が別のテーブルの日付と一致しないことを示しています。1つのテーブルにあると、すべての属性が同じ境界を共有する必要があるため、一部の属性に余分な境界が作成されます。

私が遭遇した問題は、ビジネスが変化し、突然、処理する組み合わせが増え、行数が急増し、クエリが大幅に遅くなることでした。もう1つの問題は、データを最新の状態に保つことでした。私の「スーパー」テーブルは、変更されるたびに個別のテーブルから計算されていました。

それらを分離して、ロジックをアプリ層に移動することが効果的であることがわかりました。

私が扱っていたデータは、テーブルが3つしかないことを除けば、ほぼ同じでした。可用性、価格設定、マージンがありました。事実、3つは無関係であったため、日付範囲が整列することはなく、大きなテーブルの多くの人工的な行にリースされていました。

于 2012-12-18T21:19:09.833 に答える
0

これは複雑な質問です。答えは使用パターンに大きく依存します。おそらく、ほとんどの値は毎日変化しません。したがって、データベースのサイズを大幅に増やすことができます。

一方、可用性などは毎日変更される可能性があるため、データベースにはすでに大きなテーブルがあります。

あなたの使用パターンが一度に1つのテーブルに焦点を合わせているなら、私は「十分に放っておいてください」と言いたくなるでしょう。つまり、壊れていない場合は変更を加えないでください。使用法に1つのタイプのレコードに対する複数の更新が含まれる場合、それらを別々のテーブルに残す傾向があります（したがって、1つのタイプの値をロックしても、他のタイプのクエリはブロックされません）。

ただし、使用法は、テーブルを組み合わせていることを示しています。もしそうなら、私はそれらをアイテムごとに1日1列に並べることは理にかなっていると思います。一度に連続した日数を取得している場合は、基になるテーブルに別々の日数があると、クエリが大幅に簡素化されることがあります。また、クエリが特定の時間枠に焦点を合わせている場合、提案された構造は関連データをキャッシュに保持し、パフォーマンスを向上させる余地を与えます。

ボヘミアンの言うことに感謝します。ただし、すでに最低レベルの粒度に移行しており、それが適切に機能することを確認しています。再編を進めるべきだと思います。

于 2012-12-18T22:27:44.687 に答える