Help clarify my thinking for rails associations

I'm building a rails app that allows athletes to create and manage timesheets for the sport of skeleton. I can't seem to wrap my brain around the correct associations between my models. Here's what I have so far. Athletes have Runs, which are composed of several Splits. Each individual split should be associated with a particular timing Eye on a bobsled/skeleton Track. A collection of runs on a particular date, at a particular track, and on a particular Circuit are organized into a Timesheet. An Athlete creates a timesheet, adds runs and splits to the timesheet, and then has the ability to vi开发者_开发知识库ew and graph the runs on the timesheet. Whew. Here's some code:

class Athlete < ActiveRecord::Base
  has_many :runs
  has_many :timesheets, :through => :runs
end

class Run < ActiveRecord::Base
  belongs_to :athlete
  belongs_to :timesheet
  has_many :splits
end

class Timesheet < ActiveRecord::Base
  has_many :runs
  has_many :athletes, :through => :runs
  belongs_to :track
  belongs_to :circuit
end

class Split < ActiveRecord::Base
  belongs_to :run
  belongs_to :eye

end

class Track < ActiveRecord::Base
  has_many :timesheets
  has_many :eyes
end

class Circuit < ActiveRecord::Base
  has_many :timesheets
end

class Eye < ActiveRecord::Base
  has_many :runs
  has_many :splits
  belongs_to :track
end

It seems like I make some unnecessary associations here. My biggest frustration has been associating splits with both timing eyes and tracks in the timesheet view table. Table headers are timing eyes that where turned on that day (not every timing eye is turned on every day) while table cells are the actual split times (sometimes, a timing eye misses a particular split for an athlete during a run).

Do you see any place where improvements could be made to these associations?

I suggest starting with just the minimum associations to cover your schema. Then add others later to help with the views.

Eg It sounds like

Tracks have many circuits

Circuits have many eyes

So first model that. You don't need the Eyes to belong to the Tracks too. -- That can be added later, if needed.

In the same way, a timesheet has many circuits. No need (initially) to also record the track in the timesheet. You can find the track/timesheet relationship via the circuit.

Remember that output views are essentially reports against the data. So you can easily have a desired view that will require multiple database calls or other massaging of the data to then produce the desired data for the view/report.

Eg Your report sounds like you first need to figure out the applicable timing eyes. Then, for each eye, retrieve the splits.

In the same way, for input fields, you can look up info on behalf of the user. Eg, you could make a option group select that would have groups for each track with the circuits as the individual items.

On the other hand, if it wasn't complicated then anyone could do it....