think you need a database for content management? you might not

The common prejudice prevailing today is that in order to create an effective content management system, you need to employ a database for content storage and delivery.

Now, in theory that sounds great, and the ability to say you have a "database-driven website" wins you points in certain circles. But the simple fact of the matter is, that a database may be more -- much more -- than you need to do basic content management.

By "basic content management", I mean just a way for your clients to update their pages when they wish -- to fix typos, to add text, to change calendar listings. I'm not necessarily talking about driving a completely dynamic and personalized site at the click of every button. That's far beyond the scope of most small business website needs. And it involves considerable work, the bill for which can extend beyond the budget of most small businesses.

In short, I'm about to show you why using a database for content management purposes may not be all it's cracked up to be.

How does a database make your life easier?

Flexibility
Using a database, you can generate a wide variety of types of pages displaying the same data.

Dynamic pages
A database will allow you to generate pages on the fly, with the most recent data you could ask for appearing just where you want it, when you want it.

Personalization
You can tap into your visitors' preferences and display the same content in many different ways, depending on who's asking for it.

Uniformity of information storage and display
A database forces you to store your data in predictable ways, which can mean a neater, tidier, easier-to-manage site architecture.

Information management
A database allows you to inventory all your content - your images, your text, your multimedia files... and more. And it lets you access it in as many ways as you can create SQL stored procedures.

How does a database make your life harder?

If you're going to use a database, you need a database administrator (you or someone else), and a usable schema.
You'll need to know (or learn) how to run and manage it. You'll need to configure your system, construct a sensible schema for your data, and go through the effort of architecting your database system. SQL is not terribly difficult, but it does take time, and using it is an extra step in constructing your site.

If your site architecture changes, the schema may need to change
You may need to amend your schema, if your client comes up with a brand new idea that they think would be awesome -- and that you have to implement, in order to keep their business. This can be time-consuming.

Space and technology is needed for your database
Like it or not, a database takes up space. That means storage. As well as bandwidth for sending data back and forth across the wires to update your site.

Associated Costs of Running a Database

• time to learn/master SQL
• time to costruct and maintain the schema
• time to maintain and update the DB as needed
• time and effort to learn/master the ways of connecting to the database and generating pages
• disk space and technical requirements for database setup
• lack of flexibility -- change the site, may need to change the db, which can have a ripple effect throughout all the pages/sites whihc run off that db
• added steps in keeping your site(s) up and running -- depending on how your company is structured, you may find yourself dependent on other individuals (who may or may not have time to accommodate your busy schedule and immediate needs) to make fundamental, significant changes to your db and/or schema.

So, why don't you need a database?

Running a site out of a DB can add more layers of complexity to a simple issue -- just how to generate and maintain a site with content management capabilities

Common bias says that in order to store and manage the information on a site, you need to have a database (relational or flat-file) to do so. This is not necessarily so. Think about it. If you're running a static site which does not have constant need for updates or personalization or dynamic behavior, and you simply need a way to access the content on your pages, why would you need a database? What you really need is another solution altogether -- a cgi-cms solution which lets you point into pages, get the data you need, change it, and edit html on the fly.

For a site with:

• static pages
• pages which are only changed for the sake of infrequent updates or edits
• no personalization or dynamic display

all you really need to know is how to get into a page, how to access all the objects on that page, and how to manipulate and change them on the server.

This can be done with cgi. You do not need a database to access the content on a page, when you have a means of defining and accessing it.

The Sitebasics.net Antelope cgi-cms system gives you a way of doing just that -- identifying the content on all the pages in your site(s), accessing it, changing it, and writing it back to the server. It makes the most of basic html forms and Perl/CGI to update static html pages in a quick, simple, open-source manner -- for a fraction of the effort it takes to get a database up and running and continually maintained.

Ask yourself:
What do I really want?
What does my client really need?

I challenge anyone to prove to me why they absolutely, positively, always have to use a database for content management.