ENDS 12/4: Get 50% off your Pro annual membership using code [CYBER23](https://www.codecademy.com/checkout?periods=year&plan_id=proGoldAnnualV2&discountCode=CYBER23)


Use associations to model one-to-many relationships.

Associations I

As we build more complex apps, we have to consider multiple models. For instance, what if we want to build an app with more than one kind of data, like Team and Athlete? Both Team and Athlete should have different columns and it would get messy to represent both in one model. Instead, we can represent them using two models. 

Let's see how we can use multiple models in a Rails app that helps users travel.

Adding More Data

Great! According to the request/response cycle, we need four parts to build the travel app: models, controllers, routes, and views.

Let's begin by creating the models.

Models I

Nice work. What did we just do?

1. We added two string columns `title` and `image` to the tags table
2. We added three string columns `name`, `image`, and `description` to the destinations table
3. We also added the line `t.references :tag` to the destinations table. This adds a _foreign key_ pointing to the tags table. (Foreign keys are references to rows on other tables.)
4. Finally we ran the migration to update the database, and seeded the database with the data in **db/seeds.rb**.

Display all tags

What did we just do?

We created two models named Tag and Destinations. Then, in the model files, we used the methods `has_many` and `belongs_to` to define an association between Tag and Destination. 
   - `has_many :destinations` denotes that a single Tag can have multiple Destinations.
   - `belongs_to :tag` denotes that each Destination belongs to a single Tag.

The `has_many` / `belongs_to` pair is frequently used to define one-to-many relationships. A few examples are:
  - a Library has many Books; a Book belongs to a Library
  - an Album has many Photos; a Photo belongs to an Album
  - a Store has many Products; a Product belongs to a Store

Models II

Congratulations! You built an travel app that uses a database to store two kinds of data. What can we generalize so far?

- We connected a Tag to its Destinations using _associations_. In this case, a tag `has_many` destinations, and a destination `belongs_to` one tag.
- The `has_many` / `belongs_to` pair can be used to model other one-to-many relationships, which occur frequently.
- Rails provides [seven standard controller actions](https://www.codecademy.com/articles/standard-controller-actions) can be used to do common things such as display and change data

Generalizations

Well done! The app now displays a list of tags from the database!

Show a tag

Nice job! The app displays all destinations that belong to a tag. How does this work?

- When a user visits `http://localhost:4001/tags/1`, the route `get '/tags/:id', to: 'tags#show'` sends this request to the Tags controller's show action with `{id: 1}` in `params`.
- The `@destinations = @tag.destinations` retrieves all the destinations that belong to the tag, and stores them in `@destinations`. The `has_many` / `belongs_to` association lets us query for destinations like this.
- The tag and its destinations are sent to the view to be displayed.

Show a destination

Great! The app now displays a specific destination.

Let's continue by adding actions to update a destination's name and description. Looking at the seven standard Rails actions, we need to use the `edit` and `update` actions to do this. Let's set them up now.

Update a destination I

Nicely done! You can now update a destination's name and description. How does it work?

When you visit `http://localhost:4001/destinations/1/edit` to edit a destination, it triggers the first turn of the request/response cycle:
1. The browser makes a HTTP GET request for the URL `/destinations/1/edit`. 
2. The Rails router maps this URL to the Destinations controller's `edit` action. The `edit` action finds the destination with id 1, stores it in `@destination`, and passes it on to the view **app/views/destinations/edit.html.erb**.
3. In the view, `form_for` creates a form with the fields of the `@destinations` object.

Then when you fill out the form and submit it, it triggers the second turn of the request/response cycle:
1. The browser sends the data to the Rails app via an HTTP POST request to the URL `/destinations/update`.
2. This time, the Rails router maps this URL to the `update` action.
3. The `update` uses the `destination_params` method to safely collect data from the form. It finds the destination in the database, updates its attributes, and redirects to the destination's `show` page.
