Setting Up a MYSQL Database - AJAX and the Graphing Calculator - Part 5 in a series

This series is about programming Javascript, but this particular Hub is about setting up a database, because I need a flexible and efficient way to store data that my javascript code is going to use. In the previous Hubs in this series, I introduced a Web application which will track users' locations over time so that user's can find other geographically compatible individuals. I called this application, Geomatch.

Geomatch is admittedly, a gross over-simplification of a Web application. I am basically just using it to explain a few basic principals. I promise, I will get back to javascript in another Hub or two, but javascript doesn't exist in isolation, and this behind the scenes diversion is useful to explain the larger context that javascript applications exist in.

MySQL is a relational database. Information in relational databases is stored in tables, and the power of the database comes from its ability to sort, merge and select items from tables. It is a different paradigm for manipulating data than the loops and branches of a programming language. A full explanation is a voluminous topic in its own right. I just need a place to store the data for geomatch, and I will explain the tables I created for that purpose.

The first step is to create the named database where I will store my tables. The screen shot to the right, illustrates.

For the purposes of my application, there are two entities of interest. Namely, users, and visits to locations made by those users.

My user table just has two columns in it, an Id and a string for storing the display name of the user. A real application would need to store much more: passwords, account status, secret questions, etc. However, since I am just illustrating the ideas, I can dispense with all that. The id will be used for efficiently relating the user with rows from the visit table. The name will be used for interactions with the user interface. Users will use this string to identify themselves and each other.

Because both the id and the name will be used for look up, I also created an index for each of these columns.

AUTO_INCREMENT is a convenient way to create unique ids.

It would be confusing if the same user name could be associated with more than one id. So, I used the UNIQUE keyword to prevent this.

A visit consists of who was where, when. I have used Cartesian coordinates (x and y) to simplify the mapping to graphs made by the graphing calculator. A real application would probably, use longitude and latitude internally, present users with maps that allowed graphical input of their location, and transform the data before presenting it to the code that renders the results. I'm not bothering with all of that, all three contexts, input, internal representation, and display output will use the same, simple x and y coordinates.

Who has to be a user that is known to my application. The FOREIGN KEY keyword enforces this. Visits will be searched by who and when. So, I created an index (KEY) that will be efficient for doing that.