PHP + database + webserver

12 October 2006

In a previous post I talked about how an aspiring digital historian might learn some fundamental software technologies applicable to building a dynamic website. Today I’ll try to better explain how those work together to produce web pages.

In the simplest kind of website, a person using a browser requests an HTML page by clicking a link or typing a URL. The browser then sends that request across the great wide internet to a webserver–a specialized kind of software program living on a network server. The webserver finds the requested HTML file on it’s filesystem and returns it to the requesting browser. The browser interprets the HTML and displays the resulting page on the user’s screen.

Antietam on the Web (AotW), and many other sites, however, need more sophisticated functions than can be provided by plain old HTML. In our case we’ve chosen a combination of tools including PHP and a mySQL database to help get the job done.

PHP+database+webserver flowchart_small

The chart above diagrams some of the relationships among the technlogies we’re talking about. If you are new to this, do not be alarmed, it’s fairly straightforward if you take it one piece at a time. You can click the chart to get a larger version if, like me, your eyesight isn’t what it once was.

To walk through an example of how these work together, I’ll use a popular feature on AotW: Participant search. Users looking for a particular person or military unit enter information like name or military specialty or home state in a form, and click the “search” button.

Follow along with the numbered arrows in the chart as I summarize what happens next …

  1. The browser makes a request of the web server (for officers.php) and passes along the last_name, first_name and any other values the user typed into the search form.
  2. The webserver stores the user entries in variables (vars), retrieves the requested PHP file, and takes a look at it. Because the file contains PHP commands, which the webserver doesn’t handle, it passes a request to the PHP ‘engine’ to execute them.
  3. PHP runs through the sequence of instructions in the officers.php file. In addition to formatting a page in HTML, it will …
  4. Retrieve information from the variables stored by the webserver, like the last name of the person we seek. It will also read and load other files: the standard header and footer templates and database connection routines, for example.
  5. The PHP engine will then make a request of the Relational Database Management System (RDBMS), mySQL, to have it search the pile of data for people matching the search criteria. PHP talks to mySQL in the form of a query written in SQL .
  6. mySQL looks in the data, which contains detailed information about something over a thousand individuals, and returns any records which apply–in a “result set”–back to PHP.
  7. The PHP engine completes execution of the instructions of officers.php, combines all the information it’s gathered, and returns it all formatted as HTML to the webserver. The type of page created is dependent on the data results. If the result set is empty, PHP delivers the “sorry” screen. If it sees more than one matching record, it builds a list and provides that for further selection by the user. If it finds exactly one, it fills the standard Officers page with all the details about the selected individual.
  8. The webserver then supplies the HTML page back to the requesting browser.

Voila!

__________________

Next time we’ll discuss how the Digital Historian administers his server, files, and database: looking at the right side of the chart.

3 Responses to “PHP + database + webserver”

  1. scott smart says:

    Thanls for documenting your site design. I take it the database is used mainly for queries, so I assume that design was not that important an issue, but maybe I’m wrong? Does MySQL provide much in the way of DB design tools?

  2. Brian Downey says:

    Hi Scott, thanks for coming by.

    The AotW database contains just about everything displayed on the site, all the content. The text of all the articles, and resources like the Official Reports; pointers to, and properties of all images; information for military units, indivduals, weapons, tablets, maps, and casualties; bibliographic records; site change history and configuration. I rely on database id’s (keys) to cross-reference and link officers to units to weapons to reports to stats to maps, etc.

    The database also stores new submissions from members and unfinished work staged for publication, is the basis for the peer-review and approval scheme, and manages user accounts and security/session state.

    Database design is very much an issue. Not that mine is terribly well done! It would have been better if I had known what the database needed to do in its entirety before creating the first table, but the site didn’t spring fully formed at the outset. It’s been evolutionary. I’ve had to overhaul significantly at least twice in the past 3 years or so to include new requirements as we grew. I fully expect to have to do that again.

    I use the term query, by the way, to represent any transaction to/from the database. The example above–searching for an indivdual–is common, but queries are also used to read configuration data and customize site presentation, add users accounts, promote articles to “production”, and so forth.

    I don’t know what (if any) DB design tools are available specifically for mySQL, but I’m sure the large user community would he helpful. You might start at http://www.mysql.org/ Given that mySQL is pretty much SQL-standard, and does most everything a high-end RDBMS can do, you may not need to limit yourself to mySQL products.

    YMMV!

    ps. I know I put “.html” as a file type in the diagram above, but that might be misleading. I just checked, and there’s only one html file on the site (poster.html) – and that code’s embarrassing. Everything else is built on the fly from .php templates and includes, grabbing content from the database. Some other file types are .xml .js .png .gif .ico .css

    This must be way too much information.

  3. Doing Digitial History « Bull Runnings says:

    [...] Part II [...]

Please Leave a Reply