How To Build A Web App, part 6 of ?: installing a DBMS.

I realise databases aren’t traditionally a barrel of laughs, but wow, this was the least unfunny thing about them I could find. It’ll do. In all fairness, at its best, Dilbert can be bloody amazing.

This is the sixth in a series of articles taking you through all the actual steps in building a web app. If you’re an aspiring developer, if mucking around with teensy beginner tutorials frustrates you, if you’d love to build a properly substantial app that does fab things, these articles are for you.

Last time, we talked about project management and using Git branching to keep each feature in its own self-contained parallel universe, safely isolated from the main app.

Now let’s build our first feature.

Back in Part 2, I skimmed over a brief, high-level design of our app. I promised I’d explain server apps and client apps. Here goes.

A client app runs inside your web browser. It has a UI, it displays info, you can interact with it, poke it, prod it, make it dance.

Just by itself, though, a client app has serious limitations. For the most part, you can’t save data inside it. If you refresh the page, you start again with a clean slate. That’s one job of a server. It contains the data your client app draws on. For this app, we’ll have just one server, with an attached database containing all our act/gig/venue info, and each user will have a copy of our client app running inside their own web browser, connecting to our server. It’s a hub-and-spoke model.

By the way. As I’m sure you’ve noticed by now, web development has a ton of moving parts, and a ton of

Our server will have three parts:

1. A database which stores all the data our client app(s) will eventually need.
2. A series of scripts which connect to the API endpoints (I’ll explain what that is) of the various third-party apps which supply comedian data, download that data, and store it in the database.
3. Some API endpoints of our own, which the client apps we’ll build later can then connect to, and yoink comedy data from.

Today we’ll do embark 1. Today we’ll kick off with installing our database management system, then create the Gigs database itself inside it, then hook our Gigs app up to it, and finally, add a few tables to it.

Install our DBMS

There are a ton of SQL-based database management systems kicking around (MySQL, SQL Server, SQLite, Oracle, and others). Which is best is a teensy bit beyond the scope of these articles, but PostgreSQL is one of the more popular, and has a nice long history of solidness and reliability, so I’m going with that.

Here’s a nice guide for Macs, and here’s a nice guide for Linux boxes. Luckily these aren’t too horrendous either! Use either of those to install it. It’s all good. No hurry. This article will still be here when you’re done. I’ll wait.

Create our database

Okay, let’s get our database itself set up.

One neat thing about Rails is that the builders of the bit of it pertaining to data and databases (Active Record) have deliberately made it database-agnostic. Different management systems have different SQL syntax, so when you jump from one project to another, you may have to learn each one’s specific dialect. Takes ages. One goal of Active Record is to abstract away those differences. When later articles get to Rails data/model code, you’ll see we write Rails-specific code, which among other things acts as a wrapper for the specific dialects used under the hood.

With one exception! Creating the database itself. Don’t worry too much, it’s only one command for either Macs or Linux. For a Mac, type this on the command line:

$ createdb gigs_development

And for a Linux machine, simply follow this.

There’s a rationale for calling your databasegigs_development. It’s a Rails design thing to call your databases [app-name]_[environment-name].

What’s an environment? We’ll get to that in later articles involving testing. For now, we’re using Rails’s “development” environment.

And that’s it! Your PostgreSQL DBMS now contains an empty database called “gigs”.

Next time: we’ll hook our app up to our DBMS.