2

クエリの各結果のパフォーマンス（速度）が非常に重要なプロジェクトを開始しています。

状況：

  • 約20-50製品（時間の経過とともに増加します：約3/年）
  • 各製品には、保存する必要のある約20のVARを含むプロファイルページがあります
  • 各製品の価格は変更されます（挿入/追加）---毎日---

  • 各製品には、月次、3か月、6か月、1年、3年の価格のVARもあり、ランダムに更新されます。

  • 出力1（1日あたり推定5,000ビュー）

すべての製品、当日の価格、価格差、パーセンテージ差、過去の価格

  • 出力2（個々の製品の範囲によるフォーム検索|ビュー不明推定1日あたり100ビュー）

日付、価格、価格差、パーセンテージ差、過去の価格

  • 中毒。価格のランダムな設定が必要になります。

注：このプロジェクトはExpressionEngine上に構築されています

私の主な質問は、すべての製品情報を製品IDとともに保持するテーブルを作成し、すべての製品のすべての1日あたりの価格を1つのテーブルに含める必要があるかどうかです。次に、各タイプの価格設定は一度に1つのタイプのみを使用するため、2番目の表のすべての製品のすべての月額価格設定などが異なります。

または。独自の1日の価格を保存するテーブルを20〜30個作成する必要がありますか？次に、クエリ時にJOINを使用します

私は多くの同様の質問と回答を調べましたが、十分に近い状況を見つけることができないようです。

4

4 に答える 4

1

出力1.データベースからすべての行を返すために全表スキャンを実行するときはいつでも、時間がかかる可能性があります。ただし、20〜50の製品は大きな変化であり、データベースに問題はないはずです。多くの商品を追加し始めた場合は、いつでもページ付けを導入して、1ページに100個程度の商品を表示できます。2番目のアプローチは、ホームページを設定された時間キャッシュし、定期的に更新することです。

出力2.製品IDまたはタイトルにインデックスが付けられている限り、個々の製品の検索は非常に高速である必要があります。

20〜30のテーブルを維持するのは地獄のように聞こえますが、多くの結合を行うのは悪夢です。時期尚早に最適化しようとしないでください。問題を特定するときだけ、それに焦点を合わせてください。

于 2012-09-12T05:10:52.120 に答える
0

私は常に、テーブルのセットではなく、単一のテーブルのアプローチに傾倒します。

テーブルでインデックスを使用する必要があります。これにより、パフォーマンスが大幅に向上します。

独自のロールテーブルのパーティション分割を維持するためのオーバーヘッドは、単一テーブルのアプローチをはるかに上回ります。

「エンティティ」ごとに1つのテーブルが必要です。

つまり、製品の静的データのテーブル、価格データのテーブルなどです。

于 2012-09-12T04:52:17.287 に答える
0

親子メソッドを採用します。テーブルの適切な関係を特定します。また、データの処理は、バックエンドで使用するソフトウェアによって異なります。

于 2012-09-12T04:57:40.717 に答える
0

まず、何を求めているのかが完全には明確ではありません。データを非正規化する必要があるのか​​、それともデータをパーティション化する必要があるのか​​を尋ねていますか？

第二に、両方の質問に対する答えは「いいえ」です。または、より正確には、「いいえ、お願いします、いいえ、聖なるものすべての名において-いいえ！」。

データベースは非常に小さくなります。年間365の価格変更がある50の製品は、まだ15,000レコードにすぎません。きちんと設計された「従来の」データベーススキーマが遅くなるポイントにさえ近づいていません。非正規化とパーティショニングの両方により、メンテナンスのオーバーヘッドが大きくなり、アプリケーションがより脆弱になり、開発にかなりの時間がかかります。

正規化されたデータモデルを構築し、大量のデータ（少なくとも予想される最大値の2倍）を入力し、実行する予定のクエリを実行してから、パフォーマンスを測定して問題があるかどうかを判断することを強くお勧めします。クエリ。その場合は、クエリを最適化します。それでも速度が低下する場合は、より大きな/より優れたハードウェアを購入してください。それでも速度が低下する場合は、非正規化を検討してください。それが遅すぎる場合は、Facebookで働いています。

于 2012-09-12T12:46:03.277 に答える