With all the hype about database driven website one can easily become side tracked trying to incorporate too much database into their site. The result is a slow, cumbersome site with more muscles then needed. However, with some simple and basic suggestions we can remove the unwanted overkill and focus on the needed. My focus today is on what a site requires: functionality, flexibility and usability

.

Emphasize on usability more than on anything else. Notice that the primary concern is never the need of a database system but rather the benefits using a database on your system. A database backend is a tool to achieve one or possibly all of the about requirements. Let me be frank and mention that these are not all of the characteristics of a well built website; however, they are what a site requires.


When TO USE a database

I have many friends asking me how they can implement a database into their current website. And I, before answering them how, always like to ask their reasons for wanting a database driven website. To my surprise, many ended up figuring out that a database is the only way to go. There is so much buzz today concerning the benefits of a database, yet there is no account taken into what overall functionality is lost or gained.

Let me point out that we are refereeing to database driven content for a website. I am not refereeing to collecting data or displaying data that is from other sources or that is used in other means then web pages.

I would use a database for all constantly changing content. For example, news sites need to have a database to keep track of articles. Another great example that stands out in my mind is an intranet site that I created for a Quality Assurance group. I set up a website that allowed each member of the group store and edit all their test cases in a database.

How did I satisfy the requirements of functionality, flexibility and usability? I created a central repository that allowed for creation, retrieval, and searching of test cases, which allowed for functionality and usability. I achieved flexibility through the additional features I added to the whole system; namely, printing and editing capabilities.



When NOT TO USE a database

Now, that we know the good reasons of using a database, what about learning when not to use it? This delicate question is not easy to answer. I can already feel many of you are saying, "That's ridiculous' you can always benefit from a database." Bear with me on this and let me explain.

Just because we can put it into a database does not mean that we need to. How many people use a database for the title of the site, links, images, website text (information), and other items like these? Many actually do and it is, in fact, one of reasons for my writing this article.

See, DBMS is a "Database Management System", that is it consists of a collection of interrelated data and a set of programs to access those data. Then we also have RDBMS (Relational DBMS). My point is, the fundamental purpose of a database is to provide a "logical mechanism" for the manipulation of data (information) and its primary purpose is to allow us to store the data independently of the application (Client) that uses it. Do we agree on this?

So why would we want then to put any information in a DB only to pull it back out? Probably because of the hype and buzz about database systems. This is a viable excuse, however, these issues need addressing at the time of development and design of a website.

Here are some alternatives for managing your web site content. I tend to store that information in configuration files that have arrays or other variable that can hold that data. XML can also be a good alternative.

In addition, I want to point out the fact that there are some bottlenecks with using databases. There are network problems, connectivity issues and authorization problems that can arise, not to mention the need for database management and maintenance.


Summary

When creating a web site focus needs placed on the reasons for using a database backend system to drive your site. Many times, it is easier and faster to access required data from a configuration file than connecting to a database.

We can take this one-step further. By using the database for real data and not "junk" data, if you will, we can alleviate the backend and allow for great performance. For example, if we had 15 queries to pull out website data and only three queries for actual data, think of the performance gain and usability achieved. When I refer to website data, I am talking about items that are relatively static in nature: site name, slogan, etc.

Ray "BigDog" Hunter