Introduction

I build database driven websites constantly. In fact this very website is driven by not just one, but two different databases, in two different languages, with hooks written by two different groups. They are great for what they do, and for what they provide, however they are the also the subject of many of my nightmares. Here are the reasons I hate them:

Reliability

A database website will fail. No matter what anyone tells you. No matter how much you paid, or what wonderful wording was used on that beautiful packaging. If you use a database driven website. It will fail. One night right after you published that 32 page article on why leaves are not blue, it will fail. One morning while digging through references while choking down cereal, it will fail. It will leave you completely dry. Not a page on your wonderful 10,000 page website will work, and your earnings will go from positive to nothing. Instantly.

This may not be the fault of your CMS, Ezine, or Blog. It could be some lost packet at just the right time. It may be your database, or even the servers they sit on. Could it be the hardware? Who knows. It could even have been a CPU or RAM glitch that left your ones and zeros in disarray. The fact is it will fail.

Speed

In the world of speed, static content wins. There is not a developer or programmer that will dispute that a static HTML page will completely destroy a similarly designed database rendered page in terms of speed. No matter what database you use, or language you access it with, or how optimized your algorithms are your site will never win at pure speed. In fact even when at a design disadvantage, a static page will still be faster. There is no contest here, and any web developer that tells you otherwise is bold face lying. All those requests to the database for menus, content, dates, user information, post and topic information, etc. only exist to deplete your servers ability to serve pages quicker.

Portability

Database driven sites are transferable and static HTML websites are portable. Any one who has even moved a database driven website from one server, or even from one version of software to the next, knows full well that feeling of crossing their fingers while hitting the data import function. Is the architecture right? Is the server right? Is the database the correct version? What about the language I wrote my calls in? We’ve all asked ourselves these things, and more. Database driven websites are simply not portable, and this even compounds with age. On the other hand static HTML pages are very portable. In fact you don’t even have to have a web server for it to work. Need to move a website? Copy its’ directories to a new location, and that’s it. No hooks, no importing, no problem.

Updates and Maintenance

Database driven websites need constant maintenance. This is a fact, but most people don’t understand on what level maintenance is required. As you stack software, you stack problems. The programing language you use may require a specific version or module. This version or module may require a certain version of your database or server, which may in turn require more specific modules or OS hooks. Then you may have OS requirements. All this is fine with an initial setup, but what happens when a security fix is required, or even worse, if it’s applied without you knowing. Will your site still work correctly. Maybe, maybe not.

When looking at static HTML. There is no required maintenance. In fact there are still some HTML pages that have been floating around the wide web since 1990 and 1991 when HTML was first being prototyped. Written well, static pages can last a very long time without any need or maintenance.

Resources

Static HTML sites require very little resources. With a static site you need a little room on a hard drive, and a small web server and your set to conquer the world. Static HTML sites in most cases, take up more drive space, but resource wise, that is the extent of their requirements. When it comes to database driven sites though the landscape changes quickly. You need a capable web server, some programming language, and a database capable of handling a large number of quieries very quickly. You need server hardware capable of crunching through drives quickley and repeatedly on a regular basis, and a processor that can move that data around well while processing the next hundred requests. The complexity only grows with the sites features and usage.

In short database driven websites are finicky creatures that provide great features for us as developers, yet have some serious drawbacks. In fact we, as in developers, all love them, yet the fact remains that we hate them passionatly from time to time as well. Thanks for reading …