A Primer on Relationships (with EE)

by Noah Stokes

It’s about time we got serious and defined this relationship.  You know the one where we pair a couple of ExpressionEngine entries together like an eHarmony match made in nerd heaven.  If you’ve never dabbled in the ways of Cupid, then it’s time you learn.  Relationships or Related Entries in ExpressionEngine are a simple and powerful way to reuse existing data and avoid the ultimate no-no: duplicate data.

One of the best bits of advice that I received as a young developer was to make sure that my data was only in the database once.  Database optimization, only editing data in one place, the reasons go on and on, and are perhaps best saved for an article in _DBA’s Rule The World_ magazine.  What about us EE users though?  How can we be cautious about duplicate data by taking advantage of EE Relationships? How does it benefit us, and more importantly our end users?

I’m a learn by doing kind of guy, so let’s jump right into a real world example.

For Real Estate

I recently built a website for a local real estate team.  ExpressionEngine was the obvious choice to drive the backend as we were able to customize fields to our hearts content.  We built custom fields for the obvious data: property price, number of bedrooms/bathrooms, etc. We also wanted to include some data that would be consistent through out nearly every entry, like city and related properties.

We could have easily added a custom text field for the city and make the user type in the city name and be done with it.  Similarly, we could have added an FF Matrix field and let the user type in a property address and URL for other related properties. Both of those solutions would have resulted in duplicate data in our database.  Rather than duplicating the data in every entry we needed to create relationships between the data.  This would keep our database free of duplicates and create a more streamlined interface for our end user.

Relationships are Fun

The Related Entries functionality in ExpressionEngine is a simple, powerful and elegant solution to create relationships between entries in different (and the same) channels, avoiding duplicate data and creating a pleasant end user experience.

However, if you are looking to take these relationships to the next level (second base y’all) then you may want to check out Pixel & Tonic’s fieldtype, Playa.  Playa is the diamond ring shopping in EE relationships.  If you’ve never heard of Playa, you should read up on it first and then come back. If you’re already familiar with Playa, I’m going to jump in directly with showing you how I used it. This will hopefully give you a better understanding of what it does and more importantly how it solves the problem of duplicate data.

Let’s start with the city custom field that we’re using to display city data on our Featured Properties entires. I wanted to include more than just a basic city name with each entry.  I wanted to add data like population, county and school districts.  More importantly, I only wanted the end user to have one place to update all of this information and have it propagate throughout the site. 

First, I created a channel for Cities and filled it with all of the custom fields I needed.  Then I simply created a relationship between my Properties channel entries and the Cities channel entries.  The Entry Edit form then looked like this:

A simple dropdown menu allows the end user to select a city, and thanks to the relationship the output looked like this:

The map graphic, population, county and link to more information on the city were all data from a Cities channel entry that was pulled into our Featured Property entry via a relationship.  This simple relationship displayed a significant amount of data all with an end user scenario that could not be easier: a simple dropdown selection.  What’s more, is that if this cities population changes, for example, there is only one place to update it, and it will propagate through the entire website. 

Let’s move on to another level of relationships, third base. 

Relating entries within the same channel

A requested feature for this site was to enable the end user to link to related properties from a Featured Property entry.  For example, I could link a property in the city of Alamo to other properties for sale in Alamo, giving our prospective buyer other properties to view that may interest them.  As I mentioned before, a simple solution for this could have been to use the FF Matrix fieldtype and allow the end user to add an address and URL to each Featured Property entry.  This would have been both tedious and time consuming and would have once again created duplicate data through our build. 

Our solution was to create a custom Playa field type in our Featured Property channel called Other Properties.  We set the channel to relate to itself, Featured Property.  What this gave us was a listing of all our Featured Property entries:

Now, I could simply drag and drop as many existing Featured Property entries into the new Featured Property entry that I was creating; relating multiple entires to one specific entry on the backend and creating a dead simple interface for the end user to work with.  The resulting display on the page looked like this:

This solution couldn’t be simpler for the end user—and for someone who strives to make the end user experience exceptional, there is nothing nicer.  Additionally, from a developer perspective, it couldn’t be easier to create these relationships using EE’s built in Related Entries capabilities and/or Playa.

ExpressionEngine is such a powerful solution for driving websites that at times it’s almost too easy to simply create custom fields to fit our needs without giving much thought to the idea of duplicate data.  If you can wrap your mind around some of these concepts I’ve shown as examples, I’m sure that you can begin to think of several powerful ways to use relationships in your own EE builds. 

If you’re already a relationship power user, I’d love to hear some of your examples of how you use relationships in the comments below.