Apache Says “Relax”

Posted on May 14, 2014 Updated on May 16, 2014

To me, databases are that big elephant in the room that no one wants to deal with.  They’re that essential, vital thing you have to have, but you try and convince yourself that maybe, just maybe,  you can “work around it” and delve right into the cool stuff. Do you really have to deal with this database stuff?

Yeah, yeah ya do. Face the elephant. The good news is, for this project, it’s a tiny elephant – we got this. We’ll candy-coat that tiny elephant and make it a NoSQL database. For “Pterrible Pterodacyl”, we’re going to use CouchDB. Why? Well, it’s NoSQL, append-to (because we totally don’t need to update), and well, why not. Just relax. It’s CouchDB.

Relaxed? Good. CouchDB’s plushy Futon web interface makes it quick and easy to start making our database. But first, we need to have a plan in place. What are we trying to accomplish here with our database? How can we make it scalable so we can  add fancy new features later one quickly and efficiently? What do we want to keep track of? What’s our ultimate goal?

Why do we want our database?

We want to display a high score leaderboard with a user’s name and their score.

What info will we know when a user commits score to the leaderboard?

• The name of our game (we want to record this info in case we want to make more games that utilize this database)
• Datetime when the player starts the game round (press start)
• Datetime when the player ends the game round (game over)
• The time from start to end of round
• Their score for that round
• The name of the player

What the heck does that look like in Db schema land?

Looks like we’ve got a few objects here. We’ve got the game, the player, and the player’s round information. We want to slap all that information into one centralized table where the pieces can come together, looking something like this:

A single player can have many player games. A single game can have many player games. And, for now, a player game will consist of one, and only one, round.

What the heck does this look like on the “Couch”?

Let’s make our way back to the Futon, now that we know what we’re dealing with. Let’s create a database – got it, there’s a button for that. We’ll call ours “pterobase”. Then let’s make a new tab– oh what the heck is this?

OK, new document?

What? Stop. Just stop. Let’s do a little research. So this is a document-driven, no-rules, punk of a “database”. Punk is cool. Rock isn’t dead. Let’s do this for real and look at our picture again. It’s not completely useless. We can derive “types” of documents from our tables. But the fact that we don’t have to adhere to a schema puts a little less pressure on us to get things right the first time. For now we only want to commit data to our database if the user decides to save their score.

The leaderboard round (lround) type document

This document will only be created when the player decides to “save to leaderboard”. Otherwise, we ain’t saving their info and their play information is dead to us (kind of – we’ll want to keep track of high score per session. You’ll see. We’re also doing this to cut down on size). So, what will we care about in this document?

• player name
• score
• datetime of round start
• datetime of round end
• total round play time

Do we really need to know much else? Nah. Not at the moment anyways. We’re trying to relax, remember? So, here’s what this looks like on the Couch:

And its source:

{
   "_id": "0e38ee771833be7f695c0fe660001407",
   "_rev": "2-2a287df6ce771b03f4d6ae4724811064",
   "type": "lround",
   "player_name": "King Kazma",
   "lround_start": "2014-05-14'T'16:05:00",
   "lround_end": "2014-05-14'T'16:06:30",
   "lround_play_time": "0:00:01:30",
   "lround_score": 4
}

That’s it! That’s it? Not exactly. We’ll need to get acclimated with actually doing stuff with the data in our document. That’s next time.