Relations

In Glide, rows in our Tables become items in Lists & Collections.

Each Item has properties. For example:

• A room can have a: Number, Floor, Extension, Desks, Image

• A team member can have a: Name, Number, Email, Image

• A product can have a: Name, SKU, Image, Price, Description

But what if an Item has another Item? In other words:

• What if a Room has a Floor?

• What if a Team member has a Manager? Or an Office?

• What if a Product has a Category?

These items have their own set of properties and exist as other, independent rows. So how do we connect them? Well, that’s when we use a Relation.

Single relations

Here we can see three examples of apps where items in one area relate to items in another.

• In the company app (left), Staff have Locations.

• In the conference app (middle), Talks have Speakers

• In the blogging app (right), Articles have Authors.

These are examples of Single Relations because one item relates to another item.

Multiple Relations

But often a single item relates to multiple other items.

• In this team member directory, each Location lists all the Team members that work there

• When we go to a Manager, they have a list of all the Team members they manage

Creating Relations is an essential skill in Glide because you’re connecting and making relationships between Data. Relations are also not just used for displaying lists of information; they can be used in Choices, Charts, Computed Columns, Filters, and Conditional Relations.

Matching Values

Relations relate or link items across different tables. To link items together, Glide needs to have a matching value that both items share.

Let’s look at a simple Employee Directory that has a Staff table and a Locations table.

Two tables with the column

We want to relate Staff to the Locations they work in. This will allow us to do several things, including links to their Location on their profile.

In the Staff table, we can make sure there’s a column for the name of the Staff’s Location. And of course, in the Locations table, we already have a Name column with the name of that Location.

Even though these columns have different names – the values in them are shared.

This is what we need to have before we create a Relation.

Single Relations

To create a Relation that links Staff to Locations we will:

• Go to the Data Editor and add a new Relation Column in the Staff table.

• We’ll relate items where the value in the Location column (in the Staff Table) matches the value in the Name column (in the Locations table).

We can now see that for every row, a row in the Locations table has been brought back. Now we can display and use that Relation in various ways.

Multiple Relations

Multiple Relations are configured the same way, but when many items relate to a single item, we need to check the box Match Multiple.

For example, if we want to show all the Staff that work at a particular Location, we will need a Multiple Relation because there is likely to be more than one in every Location.

We’ll go to the Locations table, create a new Relation Column, and match items where the value in the Name column matches the value in the Location column in the Staff table.

This brings back only the first staff member that works in each Location, but if we click ‘Match Multiple,’ the Relation brings back all of them.

Notice here that we had to set up two relations. 1) for bringing back the Locations to the Staff table and 2) for bringing in the Staff members to the Locations table.

Using Relations

But where do you use Relations? What are they for?

The most common use for a Relation is to display a single related item or a list of items.

In Apps, this is done with the Relation Component, Inline List, and List Relation. In Pages, this is all done with Collections.

But multiple relations can also appear in Choice Components and be the source for the data displayed in Charts. There are also more advanced uses that we will cover in a future course.

Learn more about this in the video below: