2012-03-06 5 views
0

私はニュース記事用のテーブルを用意しています。作成者、投稿された時間、各記事の語数が含まれています。テーブルはかなり大きく、100万件以上のエントリがあり、毎日10.000件のエントリが増えています。一時的に変化するデータに対するビューとテーブルの比較

このデータに基づいて、統計的分析が行われ、特定の著者が特定の時間ウィンドウで公開した単語の合計数を確認します(つまり、毎日の1時間あたり1回、毎日1回、毎月)と平均を組み合わせたものです。 Aは2011年11月4日に3298個の単語や毎日の平均で943.2言葉2ヶ月前(2011-09-04から2011-11-03まで)

  • を公開し

    • 著者:ここでは2つの例があります著者

    現在の練習はそれぞれの最後にスクリプトを開始する前に、Bが30日に午後1時と午後と13時と午後2間の163.94言葉の平均毎日の間で2012年1月21日に435個の言葉を発表カウントと平均を計算し、それを時間ウィンドウごとに別のテーブルに格納するcron-jobを使って定義された時間ウィンドウ(毎時間ウィンドウごとに1つ、毎日毎に1つ、eac h月間など)。

    合計と平均の計算はSQLで簡単に行うことができるので、ビューはこれよりも洗練されたソリューションかもしれませんが、パフォーマンスに与える影響はわかりません。

    ビューは、上記の問題の適切な解決策ですか?

  • 答えて

    1

    私はそれについてマテリアライズドビューを使用できると思います。 MySQLでは実際には実装されていませんが、テーブルで実装することができます。 Look at

    1

    ビューは、あなたの非正規化と同じではありません。

    集計番号をどこか別の場所に移動している場合は、データを正しい状態に保つために支払う特定のコストがあります。また、クエリの際に参照するデータがはるかに少なくなります。

    ビューを使用すると、実行するたびにクエリについて重視する必要がなくなりますが、元のテーブルの大量のデータを調べる必要があります。

    私は非正規化のファンではありませんが、あなたはすでにそれを行っているので、私はビューが役に立たないと思います。

    関連する問題