You've spent a lot of time perfecting your Web site, and now it's starting to grow like a weed. More and more content is starting to pour in, and you're finding yourself with less and less time for regular maintenance. The worst part is that a lot of the work is rote — you're just copying content into templates. A freakin' monkey could do it. Wouldn't it be great if you could automate the process and generate an updated site by clicking a single button? You can.
|
It seems that everywhere you turn, people are talking about the wonders of extracting Web sites from databases. But what exactly does that mean? Is your site ready for a database solution? How much work will it entail, and how much work will you save? I've got news for you: if your site has 30 or more pages, and they all share a few common templates, your site is a good candidate for a database-management solution, and you stand to save yourself a whole lot of work in the long run.
You're probably familiar with some of the more common Database names, like Filemaker Pro and Microsoft Access. But what you may not know is that a database, in its most simple form, is nothing more than a collection of records. A classic example of a common database is the Rolodex. Each card in a Rolodex is a record. Each record consists of fields — a name field, a phone number field, an address field, etc. Now, imagine digitizing your Rolodex into a single plain text file, where each record consists of one line in the file. A hard return separates each line. Within each line, the fields are separated by a common delimiter, such as a tab, a comma, or a pipe (the "|" symbol on your keyboard). The first line of the file contains the field names themselves. This is what's known as a "flat-file" database, and it could look like this:
Name | Address | State | Zip Code | Phone Number
Scot Hacker | 555 Franklin St. | CA | 98345 | 555-9394
Ed Valentine | 333 Gough St. | MN | 34099 | 555-4283
Louanne Smith | 222 Blunt Blvd. | CA | 96352 | 551-4526
The interesting thing about a database is what you get when you look "down" through the records, rather than at each record individually. For instance, I can search this example database for people living in CA (Scot and Louanne), or for people whose phone numbers start with 555 (Scot and Ed). Large databases with thousands of records and hundreds of fields per record can return fascinating results.
There are many more complex forms of databases, such as "relational database management systems," where lots of tables share connected fields, but we're going to keep it simple in this tutorial.
Because managing a flat-file database as a plain text file can quickly become unwieldy, most people use commercially available databases such as FileMaker Pro or Microsoft Access. These give you convenient tables, fields, and record forms into which you can paste your content. They also make it easy to perform complex "data-mining queries."
What does all of this have to do with your Web site? Imagine that the example above stores the pages of your site rather than your friends' addresses, like this:
Page Title | Author | Date | Page Color | Illustration | Content
Database 101 | Scot Hacker | 4/15/98 | Yellow | picture.gif | We'll begin by...
My Fiction | Louanne Smith | 3/10/97 | Light Blue | fiction.gif | Once upon a...
Now imagine that you could take one of your site's pages and replace its content and HTML code with the field names from your database. We'll call this new file your "template." Then imagine you've got a magical script or program that would cycle through your database and create an HTML page for each record, matching field names in the template with field names in the database. While it's working, it would also create an index, or linking page, so you'd have a menu page linked to all the pages on your site. What might take you five minutes per page manually can be done by this system in a second, with no human error.
In a nutshell, that's the magic of database-backed Web sites. But how this process is actually accomplished varies widely. Beyond the flat-file database, there are dozens of commercial database products out there, and there are dozens of different systems used to extract HTML from those databases. Some store the database on the Web server itself and use CGI programs to build Web pages on demand (your favorite search engine is a good example of this). Others store the database on the user's computer and build HTML pages which need to be uploaded to the server later. Some deal with immense, million-record databases and have to be operated by certified (and highly paid) Database Administrators, while others deal with smaller databases run by untrained individuals. Some work via external scripting systems like AppleScript, while others depend on query systems built into the database itself.
Since you're probably running your site on an ISP's server or here on Tripod, and are therefore not allowed to run fancy-pants programs on the server itself, I'm going to look at a couple of simple, low-cost solutions you can run on your own computer. These will generate "static" HTML pages which you can then upload to your server manually. I'm going to assume that you have a little experience using a commercial database program such as FileMaker or Access, although these techniques both work with just about any database program out there.
TIP: if you're using Access, which comes with Microsoft Office, note that any field you intend to hold more than 256 characters — such as your Content fields — need to be marked as Memo fields, not Text fields. Otherwise your content will be truncated when you paste it in.
|
|
|
