Model creation

I'm building an app for my oldest daughter who is a competitive swimmer. The app will allow her to track each meet and every race. Eventually, the plan is to show her progress, trends using graphs, and track her points for State.

Currently I have two models:
First is for Events (or race)

create_table "events", force: :cascade do |t|
t.string "style"
t.string "distance"
t.string "seed_time"
t.string "time"
t.string "heat_place"
t.string "overall"
t.boolean "team"
t.string "points"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end

The next model is for meets

create_table "meets", force: :cascade do |t|
t.string "host_team"
t.string "event_name"
t.string "event_location"
t.date "date"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end

The goal is to simplify inputing the race information. She's 8 yo and I want to allow her to choose from swimming styles (i.e. freestyle, breaststroke...) I pre-populate in order to sustain continuity.
Do I need to create a new model that is specific to "Style"? Or Can I build into the form the ability to choose from a dropdown?

create_table "styles", force: :cascade do |t|
t.string "style"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end

Same question with distance:
In the US, most of the pools are measured in yards (which is really $#@%ing annoying)
Is it better to create another model specifically for distance?

create_table "distance", force: :cascade do |t|
t.string "distance"
t.string "measurement"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end

And Should Event look like this:

create_table "events", force: :cascade do |t|
t.string "seed_time"
t.string "time"
t.string "heat_place"
t.string "overall"
t.boolean "team"
t.string "points"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end

Am I overthinking this????
Any help would be greatly appreciated.

2 thoughts on “Model creation”

  1. Hey there,

    having a dedicated model for the style and distance is one option ([example](https://gist.github.com/tbuehlmann/4c14c401be79559edff6b86a7f31bd38)), another one would be to use an enum ([example](https://gist.github.com/tbuehlmann/256f56aebe7dfe11f5646d3570f2e5f3)). Enum’s big disadvantage: You’d have to change your code if there’s a new style or distance. If there’s a new style/distance with the model option, you could add it via the app itself. So I personally would go with the model option.

    “Or Can I build into the form the ability to choose from a dropdown?” is possible in both cases. For the model option, there’s even a [helper method](http://api.rubyonrails.org/classes/ActionView/Helpers/FormBuilder.html#method-i-collection_select) for that.

    Reply
  2. Hello,
    that’s great that you’re developing this for your daughter. My father built me a bookshelf 20 years ago and I’m still using it. Who knows? 🙂

    I wouldn’t use a model for styles, as you mentioned, it doesn’t change that often. And for the measurements, I think if you choose a measurement and stick with it, the data would be consistent and it would be easy touse for the graphs.

    For the event, it would be nice to create an event like an appointment on a calendar (with an additional date column) so that she knows when she has to attend a race. And with the update action, she can add her score (if that’s what it is called.)

    Reply

Leave a Comment