Setting Up a MYSQL Database - AJAX and the Graphing Calculator - Part 5 in a series
Create the Database
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.
Create a User Table
Details about the user table
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.
Create a Visit Table
Details about the visit table
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.