2012-01-15 7 views
0

サッカーマネージャーゲームを作成するために、Match、Teamなどのルーチンのモデルを作成し、マッチモデルの属性(ショット数、ショット数、ファウル数、コーナー数など)として多くの統計情報を追加しました。私はそれぞれのハーフフレームについて統計を提供したいと思います。したがって、私はHomeTeamFirstHalfGoalsやAwayTeamSecondHalfCornersのような属性を作成しました。私はマッチモデル内データベースクエリのオーバーホールを最小限に抑えるためにデータベース/属性番号を設計するにはどうすればよいですか?

HomeTeamTotalGoals = HomeTeamFirstHalfGoals + HomeTeamSecondHalfGoals 

などの合計を計算し、ユーザによって要求されたときLeagueTableとして、一部またはすべてのこれらの統計情報を表示するように計画しています。私は、ユーザーが先週、またはTotalGoalsなどの計算可能な属性や特定のチーム/シーズン全体のマッチリストを含むすべてのフィクスチャで行われたすべてのマッチのように、異なるテーブルを見たいと思うかもしれません。

ただし、コードの処理が遅すぎます。私はそれが開発環境に起因するのかどうか、mysqlについての知識と混乱が少ないので、マッチテーブルをどのように設計すればいいのだろうと思います。

質問は(AwayTeamSecondHalfCornersのような)属性の数を最小限に抑え、依存するもの(TotalGoalsのようなもの)を計算すれば(私が見ているように、データベースクエリの概念を聞いてから、サーバーの時間とCPUがかかります) )をオンザフライで実行するか、またはサーバーのオーバーホールを最小限に抑えるためにその逆を実行しますか?

注:ExcelでA3 =(A1 + A2)と入力して新しい列を作成するのは簡単だと誰もが知っていると思います。私はそれがRubyのビューでこれほど簡単かどうか、またはmysqlテーブルでそれを行う方が効率的かどうか混乱していますか?私はプログラミングの背景がないので、簡単な情報源への案内は大歓迎です。

+2

あなたは何が遅いの時間をする必要があります。その場を飛ばして一般的な質問をすることはできません。タイマーを追加し、問題がどこにあるかを確認します。 1つのクエリであれば、ここに投稿する必要があり、お手伝いできます。欠落しているインデックスのようなものかもしれません。クエリーの量が多い(クエリーが速いが、それらが致命的なものである)場合、各クエリーを少し早くするために、より小さな変更(アトリビュートでランダムに提案するような)を行う必要があるかもしれません。それ以上の知識がなければ、助けるのはちょっと難しいです;) – Nanne

+0

ガイダンスをありがとう。 "SQL> SET TIMING ON"を実行すると、クエリーの実行に時間がかかることはありません。 – barerd

+0

おそらく、まだパフォーマンス測定サービスに向かう価値はないでしょう。ベンチマークや、start_time = Time.nowのような単純なものから始めます。 #code-in-question-goes-here; end_time = Time.now; duration_in_seconds = end_time - start_time' –

答えて

0

これにアプローチする方法はたくさんあります。まず最初に、コードのどの部分が高速かどうかを確認することです。Rubyのベンチマークライブラリ(http://www.ruby-doc.org/stdlib-1.9.3/libdoc/benchmark/rdoc/Benchmark.html)を使用します。

一般に、すべての離散データを格納し、離散データから導出できるすべてを計算する方法を定義することをおすすめします。チームの目標は次のようなものになると言います。

def total_goals 
    first_half_goals + second_half_goals 
end 

その計算を行うためには、どのようなロジックが必要ですか。このような算術演算は非常に高速で、コードの苦情は発生しません。

大きな減速の原因の1つは、データベースにインデックスがない場合です。外部キーを持つときはいつでも(通常_idで終わるもの、たとえば、ゲームにaway_team_idとhome_team_idがある場合などです。おそらく両方の外部キー)、データベースに対応する索引があるはずです。インデックスを追加するには、新しいデータベースの移行を作成し、その後、このようないくつかのコードにドロップします。

class AddIndexes < ActiveRecord::Migration 

    def self.up 
    add_index :games, :home_team_id 
    add_index :games, :away_team_id 
    end 

    def self.down 
    remove_index :games, :home_team_id 
    remove_index :games, :away_team_id 
    end 

end 

つまり、チームは非常に大きなマージンが演じるというゲームを探している任意の時間をスピードアップします。

+0

したがって、「このような算術演算はかなり高速で、コードの苦情は発生しません」。 CurrentGoalsやCurrentFoulsのような属性を各試合後に計算され修正された個々の選手やチーム(全シーズン中に得点された選手やチームの合計ゴールを示す)に入れて、それらを使って選手や選手を選ぶ異なる種類のテーブル。言い換えれば、これらのような算術体を使ってモデルを過度に埋め込むことに問題はありません、それは正しいのですか? – barerd

+0

2番目の見方では、home_team_idとaway_team_idは実際にはteam_idにすぎませんが、Matchモデルの作成中にteam_id:referenceを使用することはできません。だから、この "AddIndexes"はジョイントテーブルなので、私が間違っていなければ、なぜ単にmatch_idとteam_idをIndexesにだけ入れることができないのですか? – barerd

+0

AddIndexesは実際にはジョイントテーブルではありません。これは、指定したテーブルやフィールドにインデックスを追加することです。 'add_index:games、:team_id'と言うだけでうまくいくでしょう。重要な部分は、外部キーを持つ各テーブルが各外部キーのインデックスを取得することです。 –

関連する問題