0

Railsは比較的新しいので、数人の友人がnflゲームをハンディキャップするためのシンプルなRailsアプリに取り組んでいます。

ホームチーム、ビジター、start_timeなどのスポーツゲームに関する情報と、そのゲームのハンディキャップに関連する情報（お気に入り、アンダードッグ、合計など）をモデル化するアクティブレコードモデルを作成しています。

基本的に重複した情報を保存しているこれらのフィールドのいくつかのために、これは厄介な感じがします（たとえば、チームは常にhome_teamまたはvisitorであり、常にお気に入りまたはアンダードッグです）

したがって、私のモデルは次のようになります。

create_table "games", :force => true do |t|
    t.integer  "week"
    t.string   "home_team"
    t.string   "visitor_team"
    t.string   "favorite"
    t.decimal  "line"
    t.decimal  "total"
    t.string   "kickoff"
    t.string   "status"   #['open', 'completed']
    t.datetime "created_at",   :null => false
    t.datetime "updated_at",   :null => false
end

モデルをできるだけ軽くするために、必要なフィールド（ホームチーム、訪問者、お気に入り、合計）のみを定義し、ゲームモデルにいくつかの簡単なメソッドを記述して、マッチアップに関する他の有用な情報を返します。モデル内で2回チームを組む（1回はアンダードッグ/お気に入りとホーム/アウェイ）

def underdog
    teams = [self.home_team, self.visitor_team]
    teams.each do |team|
        return team if team != self.favorite
    end
end

これは機能しますが、ゲーム情報用に個別のモデルを作成し（そして、ゲームモデル自体を最小限に抑える）、has_many =>：throughを使用するか、他のアプローチを試してみる方が理にかなっているのかどうかを議論していました。セットアップは、同じテーブルに重複する情報を格納するのが正しいとは思えません。任意の提案または感謝します。

4

2 に答える 2

1
  1. 手始めに、データベースの正規化を調べてください。
  2. 他の複雑な問題に対処する場合を除いて、派生/暗黙のフィールドを保存しないでください。例えば。パフォーマンスを向上させるためにそれを行うこともありますが、欠点/リスクを理解しています。この状況では、（a）ホームチームを知っていれば、訪問者を導き出すことができます。（b）同様に、お気に入りを知っている場合は、弱者を導き出すことができます。（ラインについてはわかりませんが、チームに関する情報が含まれている場合は、そこからお気に入りとアンダードッグを導き出すことができます）。

リファクタリングされたコードは次のとおりです。

def underdog
  home_team == favorite_team ? visitor_team : home_team
end

幸運を！

于 2012-06-11T04:04:53.323 に答える
1

これは私には問題ないようです。一般に、has-many-through関係は厄介で複雑であり、ほとんどの場合不要であるため、使用を避ける必要があります。

ただし、この場合は、実際にTeamモデルを作成することをお勧めします。NFLであるため、これらのチームは変更されませんが、それを引き出すことで、データベースに入力する必要のある文字列の数を減らすことができます。

また、元のメソッドをリファクタリングします。

def underdog
    if home_team == favorite_team
        home_team
    else
        visitor_team
    end
end

returnRubyでは、メソッドの最後のステートメントが暗黙的に返されるため、明示的に呼び出す必要はありません。また、Rubyでこのようにループを使用すると、悪い形式と見なされます。

また、モデルメソッドでいつ使用するかについては、この記事を参照してください。self

于 2012-06-11T03:55:33.160 に答える