I can sure sympathize, Terri. Like you, I started with a fairly small site, just a few hundred pages, in FrontPage. Like you, I kept adding new content and, like you, I used FP includes to help manage the growth. And, yea, like you, I soon discovered the down-side to my strategy. FrontPage simply is not equipped to deal well with large sites. I think I've had relationships that didn't last quite as long as it took FP to update a 5000-page site.
As you've surmised, a database is definitely the way to go. I made the switch over five years ago, and have never looked back. There are some hidden assumptions about a database-driven web site, however, that need to be questioned, because those assumptions are going to color your decision.
This page, with all our posts on it, doesn't really exist, except as a series of records in a database. Every time someone asks to read this thread, the page is dynamically generated and sent directly from the underlying program to someone's web browser. It never gets written to disk as a "page." It makes a whole lot of sense to do it this way because the contents of the thread changes every time someone makes a new post to it. The content is highly dynamic, ergo the web page is dynamic.
I took a look at one of your sites, Terri, and like my old FrontPage situation, your data really isn't all that dynamic. Once you've added a new Project Sheet, the actual content probably changes very rarely, if at all. Any changes you might make would be "controlled" changes, in the sense that you control what and when, which is quite unlike this thread in a public forum. There is a hidden assumption on the web, I think, that a database-driven site necessarily results in dynamically generated pages like this one. In truth, though, this page is dynamic because the
content is dynamic, not just because it comes from a database. Web sites with data that is more typically static, even if that data is held in a database, need not necessarily result in traditional dynamic pages.
Here's what I did.
All of the content on my site is stored in a relational database. I chose to work off-line, in a local DBMS (MS Access), but the same exact concepts would work equally well on-line. Each pertinent record in the database contains both a category field, which translates to a directory, and a file name. Also included is a pointer to an HTML template, which itself is composed of elements that translate very closely to your FrontPage includes. I click a button and Access churns through the database, plugging the content into templates and writing each to its own directory and file name combination. It takes about fifteen minutes to create roughly 18,000 web pages. If I make a change in a header, footer or menu, I simply recreate the whole web site.
As far as the web server, visitor, or search engine are concerned, these are all
completely static HTML pages. There's a lot of advantages to that, not the least of which is that none of my pre-database links were ever broken. There are also some disadvantages, of course, but for me (and, I suspect, for you) the advantages FAR outweigh the disadvantages.
The concept of dynamically created static pages (it only sounds like an oxymoron) isn't "new" technology, by at any means. Seven or eight years ago, it was much more common on the web, but as hardware grew faster and more capable of pumping out pages on the fly, we moved in a different direction. With bell bottoms and hip huggers making a come-back, maybe it's time to revisit some old technology concepts as well.
