First let me say there are many different ways to implement this. It
depends on your particular needs.
So I will try to break down the conventional approach presented by
Ruby on Rails.
You are describing two resources: a Player and a Result. This would be
represented by two models and in turn two database tables.
The models would be named Player and Result. The database tables and
resource routes would be the plural of those (i.e. players and
You would have the the following routes for manipulating those
When you GET (as in HTTP GET method) on /players you are asking for a
list of players. This will be handled by the index action and players/
index.html.erb page in your controller and view respectively.
If you POST to that same /players route you would be asking the
controller to create a new Player instance and save it to the players
database table. This is handled by the create action in your
players_controller. Of course, there also needs to be a way to ask
(GET) the form used to provide the attributes for a new player. You
accomplish this by sending a GET request to the /players/new path.
This means “Get the form used to submit a new player.”
Similarly, If you PUT to the path /players/1 you are asking the
players_controller to update an existing player who’s id is 1. Like
new there is also the /players/1/edit used to get the edit form for
the player with id 1 where the user would be presented the template
represented by players/edit.html.erb.
Now this is an over simplification of how the system works, but
hopefully it will give you some direction on what to study. My first
suggestion is to find and read all you can on Model-View-Controller
design pattern and on Representation State Transfer (REST). Without a
good understanding of these architectures you will be constantly
confused by Ruby on Rails.
P.S. You mentioned having an admin interface. There is a facility in
Rails to supporting admin interfaces separately from standard
interfaces, but I’m afraid that topic is too advanced for your current
level of experience with Rails. My suggestion would be to avoid the
notion of a separate admin interface until you understand the basics