Design Choices

There are two fundamentally different approaches to creating a dynamic web application that is backed with data. The first is to employ relational data tables in a database (MySQL) to store, search, and retrieve data. I would then use PHP to communicate with the database, serving as the link between the web html and the MySQL database. The advantages of this approach are two fold. First, it makes search and sort operations very simple. Secondly, it supports a growing data set in a natural and well organized fashion. The downside is that this design is fairly rigid once building begins. After the various tables are defined to capture the desired data, it becomes extremely difficult to redesign or augment the data tables to encompass more or different data.

The second option is to use text files and file readers to act as a pseudo-database. The advantages here are essentially the reciprocals of the disadvantages of the database design, and visa versa. While text files can be much more flexible to changes, they make search and sort operations far more costly.

Together with Professor Nimeroff, I've decided to design and implement a true database for this project. This choice means that my focus and time will be primarily geared towards building a functioning database that can be manipulated dynamically by users.

Because I have no experience with databases, PHP, or servers, I am currently studying the theory and syntax of these various aspects on my own. I've installed MySQL, Apache, and PHP on my laptop and have already experimented with these tools. Below is a relational table that I created and manipulated with MySQL Query Browser:

The first step in designing a database is to lay out all of the tables that you'll need and the information that they'll contain. Because of the above mentioned drawback of databases, this step is critically important. The time spent perfecting these tables up front can save that time 100 fold down the road. There is a 3 step process explained in the MySQL book I bought for designing and flushing out data tables. I went though the first step and I'm currently on the second. These "steps" exist to help identify and eliminate redundancies in the data, making the database maximally efficient. Below are the tables (and their contents) that I have thus far:

The two biggest issues right now are how to handle appointments and how to handle an array of services (manicures, pedicures, massages, etc) beyond simply haircuts. For appointments, it seems natural to create tables that mirror the structure of a schedule. But, this would mean creating tables for each day, for each stylist. Intuitively this doesn't sound like a good thing. So for now, I have appointments modeled as stand alone events that get pushed onto the bottom of a growing table, and contain the critical information. This choice is still very much up for debate.

As for services, I can't figure out how to model them in terms of tables without ending up with one table having to store arrays. I'm not sure if storing arrays as table elements is possible or advisable. I'm going to have to discuss this with Professor Nimeroff and figure out if there is a way to capture this data soundly. If not, I may have to limit the scope of the website to just haircuts, and the basic services that accompany them (like coloring, highlights, perm, etc.).