Hardcoding versus Database Driven Data

When working on web applications, it is almost inevitable that at some point the issue of database driven data will be brought up. After all, one of the benefits of having rich business logic in our web applications is the ability to always have pertinent, changing data available to the end user. Hardcoding data or information is looked at as an archaic testament to the static web pages of past. However, even though a good web application likely contains a significant amount of database driven data, making everything database driven can be a mistake as well. Here are a series of questions you can ask yourself when determining the data strategy for various parts of an application:

How Often Will The Data Change?
This should be the first question asked, as it is one of the most important things to consider. Hard coded information can only be changed by changing the actual code on the file itself. That means that every change is subject to the release process - going through Quality Assurance, User Acceptance Testing, etc. And since many organizations only release code to the production environment at predetermined intervals, the change make take three or four months before it actually makes it out to the production servers. Database driven information, however, is usually easier to change, and can often be changed through a user interface in the application itself. So data that will change frequently is almost always better as database driven.

Is Performance An Issue?
This is the biggest disadvantage of using database driven information. Every call to the database takes time and resources. These days, it is not uncommon for a web server to be located in a completely separate location than the database, sometimes not even in the same city or state. So each request to a website has to absorb the communication time for all of its DB calls. A web page with multiple calls to a database can take significantly longer to load than a page with hard coded information. If performance becomes an issue on a web application, one of the first places I look is the number of times the database in being hit.

Is the Application Operating In A Clustered Environment?
If an application is running on multiple servers, storing data in a shared database is a good way of ensuring that the same information is being presented regardless of the specific server serving the request.

Does The Initial Investment Offset Long Term Maintenance Cost?
The initial investment with a database driven strategy will almost always cost more than hardcoding.  Hardcoding information is simply easier and less demanding.  Even though all changes are subject to the release process, those changes are usually substantially easier to test and deploy than any kind of content management system or user configurable interface.  Keep in mind though that this is one of those areas where spending a dime now can save a dollar later.

In summary, if the application is working on a short budget or time line, or if the data isn’t going to be changing frequently, or if performance is a concern, then hardcoding may actually be a better option (as archaic as that sounds).  Making everything database dependent can introduce complexity without benefit, and sometimes the best solution is the simplest one.