I had a conversation with Karl the other day, about static vs. dynamic implementations for a website.
Depending on how many page views you have per hour on the server, a dynamic implementation could slow down a site unnecessarily.
The important analysis is this one: divide the number of content changes in a given time by the number of page view requests for a given page. The closer that number is to zero, the more static your content is. The closer it is to one, the more dynamic it is.
My content is definitely more on the static side. I add pages every now and again, edit them every now and again, and of course, update my weblog fairly regularly. I don’t use a database back-end, but I do use a fair amount of PHP to hold things together.
I use PHP because it makes maintenance easier. I don’t really use it because my content is dynamic – so it could be seen as “abusive” use of a dynamic implementation. However, I don’t have so many visitors that it does make a difference to the server.
If the server load did become too important, however, I would certainly consider putting in place a script that would generate a static version of the site (each day or on demand). Visitors would access the static version, but it would be easily produced by the “generator script” on the basis of the easy-to-maintain dynamic version.
What is your opinion on the subject? Are “dynamic” website implementions being used abusively? Under what conditions do you consider using a database as a back-end? Do you have any numbers or statistics which either validate or invalidate the theories exposed above?
I’d love to hear from you. Add your comments below.
I like the solution of having a static site created by a backend engine:
+ you have the speed of the static site
+ you have the convenience of a CMS
Of course, that means no “dynamic” goodies like RSS feeds of other sites,
no “you visited me N days ago” and other personalized content.
Or numbers of comments for a specific article.