Exercise: Databases

Time to put our database thinking to work!

In this exercise, we’re going to take a simple list of Athens coffee shops, turn that list into structured data, and then use WordPress to store, interact with, retrieve, and present that information.

Our process will be:

STRUCTURE → STORE → INTERACT → RETRIEVE → PRESENT

STRUCTURE: Build the Data

Start with our collection of Athens coffee establishments:

  • 1000 Faces
  • Bitty & Beau’s
  • Buvez
  • Cafe Racer
  • Hendershot’s
  • Jittery Joe’s
  • Molly’s Coffee Company
  • Sips Espresso Cafe
  • The Rook & Pawn
  • Walker’s Coffee & Pub

Create a new Google Sheet and put each establishment on its own row.

Now we need some fields!

As a class, decide what information would actually be useful to someone trying to choose a coffee shop.

Possible attributes could include:

  • Neighborhood
  • Local or Chain
  • Outdoor Seating
  • Food
  • Study Friendly
  • Dog Friendly
  • Hours

Don’t just add every possible field you can think of.

What information would actually be useful to collect?

Add the attributes we choose as column headings.

Think About Your Values

Now add some information about the coffee shops to the spreadsheet.

As you work, pay attention to places where the data gets messy.

For example, if we have an Outdoor Seating field, are Yes and No enough?

What should we do if:

  • we don’t know?
  • seating is seasonal?
  • the answer varies by location?

Don’t worry if the answers aren’t obvious. That’s part of the exercise!

Create a Taxonomy

Next, look for repeated values and useful ways to group our collection.

We need to decide which information would work well as Categories and which information would work well as Tags.

Remember:

Categories organize. Tags describe across that organization.

For example, we might decide:

Categories

  • Downtown
  • Five Points
  • Boulevard
  • Normaltown

Tags

  • Local
  • Chain
  • Outdoor Seating
  • Dog Friendly
  • Study Friendly
  • Serves Food

Now ask yourself:

What will this structure allow us to retrieve later?

MAP: Translate Your Model to WordPress

Our spreadsheet represents our conceptual model.

Now we need to figure out how to implement that model in WordPress.

Regular WordPress Posts provide:

  • Title
  • Content
  • Excerpt
  • Featured Image
  • Categories
  • Tags

Decide where the information from our spreadsheet should go.

For example:

Name → Post Title
Neighborhood → Category
Amenities → Tags

Not everything will map perfectly.

That’s okay!

Conceptual model ≠ implementation.

Part of working with an existing framework is figuring out how to use the structures it already provides.

STORE: Open WordPress Playground

Visit:

WordPress Playground

WordPress Playground creates a temporary WordPress installation right inside your browser.

First, create the Categories we decided on as a class.

Then create a new Post for one of our coffee shops.

Your Post should include at least:

  • Title
  • Content
  • Category
  • Tags

You may also use an Excerpt and Featured Image if they make sense for our model.

Publish your Post when you’re finished.

Then repeat the process until we have 2–3 coffee shops stored in WordPress.

Look Behind the Curtain 👀

We’ve entered our information into WordPress, but where did it actually go?

Open WordPress Playground’s Database controls.

Open phpMyAdmin and locate:

wp_posts

Look through the records and see if you can find one of the coffee shop Posts you just created.

Once you find it, identify:

  • the table
  • a row / record
  • a column / field
  • a value
  • the Post’s ID

Compare what you’re looking at to our Google Sheet.

What looks familiar?

You’ll also notice that WordPress stored much more information than we explicitly entered.

That’s because WordPress needs additional data to make the application work.

You are not expected to understand the WordPress database structure, and you should not edit anything directly in the database.

We’re just visiting. Say hello to the database and get outta there. 👋

INTERACT: CRUD

Return to the regular WordPress interface.

Let’s perform all four CRUD operations.

Create

Create and publish a coffee shop Post.

Read

View the published Post.

Update

Edit something about the Post and save your changes.

Delete

Create a temporary test Post and move it to the Trash.

You just:

Created
Read
Updated
Deleted

some persistent data.

CRUD!

RETRIEVE: Put Our Structure to Work

Now let’s see why we bothered organizing our information. Open one of your coffee shop Posts and click its Category.

What does WordPress show you? Try another Category.

Now click one of your Tags. Again, pay attention to what WordPress retrieves.

Think about the following:

Did we manually build this page?

Did we copy the coffee shop Posts onto it?

Why did WordPress know which Posts to display?

WordPress can retrieve these particular subsets because we gave our data structure.

STRUCTURE makes RETRIEVE possible.

PRESENT: One Record, Multiple Views

Pick one of your coffee shops and see how many different places you can find it.

Can you find the same Post in:

  • its individual Post view?
  • the main Posts listing?
  • a Category archive?
  • a Tag archive?

Remember, WordPress isn’t storing a separate copy of the coffee shop for each page.

It’s retrieving the same stored data and presenting it in different contexts.

Data ≠ Presentation

Put It All Together

Think back through everything we just did:

STRUCTURE
We decided what information mattered and how to organize it.

STORE
We entered that information into WordPress.

INTERACT
We used CRUD operations to work with our data.

RETRIEVE
We used Categories and Tags to access meaningful subsets of the collection.

PRESENT
WordPress displayed the same stored data in different contexts.