Database-Driven vs. Static HTML Sites

A small site that features only a few products, like NoteTab.com, can easily be made and maintained using nothing but basic HTML code that almost anyone can teach himself or herself to write in a few days. These are "static" pages. If most site elements (logo, links, etc.) are going to be on all pages, they don't need to be rewritten "fresh" each time you change a page's content or add a new page. But when you get to the point where you are carrying more than about 100 products, each of which requires an illustration, and each of which may be subject to frequent price changes, you will be better off using a database and creating dynamic pages instead of static ones.

When a user's browser calls for a page, and you're operating a Web site that runs on static HTML, the process is simple. Your server sends a single file that contains all the words and HTML code needed to recreate that page on the user's screen, plus a separate piece of code for each picture. Keep your HTML simple and the number (and size) of pictures down and each page will load quickly. Things at your end are simple, too. Since there aren't a lot of files involved with making up each page, your server computer doesn't need a very fast hard drive or much processing power. You don't necessarily even need a computer designed as a server to do this job, and you may even be able to avoid paying an outside provider to host your site. If you have (or know someone who has) enough technical know-how to install Linux and Apache, the most common software ingredients in a low-cost server installation, and you have a DSL Internet connection, you can serve thousands of pages daily from almost any old computer you have laying around.

Sites running "back-end" databases are more complicated. Instead of having each page stored as a single entity, dynamic sites (as these are called) assemble each page from parts, and put those parts into a pre-determined template every time a user's browser sends a page-request signal to your server. Instead of accessing a single HTML file and several graphics files in order to send a page, a database-driven site may access a separate file for each block of text displayed, plus a file for each graphic, plus the template file for the page, then send all of these files to the user, whose browser then uses them to construct the page. The more text blocks and pictures on a page, the longer all this takes. To compensate, we end up using expensive, specialized server hardware to get the same results we could have gotten serving static pages from a castoff home computer, and because your server and the customer's must talk back and forth more times for every page put out than is needed for a static site, this means more bandwidth gets used. Even if you use free Open Source software to run a dynamic site (and there is plenty of excellent free software available out there that can do this), increased hardware and bandwidth expenses mean you are going to spend a lot more money to run a dynamic site than to operate a static one.

So why bother?

Look at the MexGrocer.com screenshots again. The pictures and product descriptions you see may be used on many pages. A dynamic site like MexGrocer.com can produce a page that contains pictures of all products sold under a preferred brand name (Victoria), of all products in a given category (salsas), or of all products needed to make a particular dish (enchiladas). A dynamic site can give a user the option of viewing "all scanners under $150" or "all residential real estate listings in Wellington, New Zealand with asking prices between $50,000 and $120,000." A dynamic site gives users more information layering options than a static site. It is also easier to maintain in the clerical and content sense than a static site. On a static site, if you display a product on three different pages, and you discontinue that product or change its price, you must make those changes three times. On a dynamic site, you need to change a product's database entry only once, and it will be deleted (or added or modified) everywhere it could conceivably be displayed on your site.

Another advantage of a dynamic site is that it can draw information from an existing product or inventory database. The same text and illustrations can be used to generate both a print catalog and an online virtual catalog, which cuts expenses for both if they are either made by the same production crew or by offline and online marketing crews that work closely together. The next step in full utilization of a product database is to tie it to inventory and purchasing and to make it a true end-to-end ERP (Enterprise Resource Planning) tool that not only helps make sales, but also manages other aspects of your business including ordering, inventory, and future resource needs. Or take it from the other direction: If your company is already using an ERP or inventory control database of some sort, use that as the basis of your Web site. The cost of adding a few fields to an inventory database (like photos and customer-friendly product descriptions) so that it can become the basis of a catalog-style Web site is tiny compared with what you spent to set up the ERP database in the first place.

The problem with all of this database work, especially for small entrepreneurs, is that it is not cheap. Setting up and maintaining a workable, large-scale, database-driven ecommerce Web site is a full-time job for professionals. You may be able to hold costs down somewhat by hiring freelancers or an outside company to design and set up the site, and you may also be able to rely on outsiders to do most of its ongoing technical maintenance, but you will almost certainly want to have at least one in-house Web project manager to make sure everything works right someone who spends a fair amount of his or her time simply calling up pages on the site to make sure that they all display correctly, and is responsible for making sure product descriptions, prices, and illustrations are always up to date. This person need not be a programmer, systems administrator, copywriter, or graphics designer, but should have at least some knowledge of what all of these people do and how to get them to work effectively.

How much of the work should be done in-house, versus farming it out, is one of those questions that must be answered case by case. If your company is large enough to have a sizable IT department anyway, you might as well keep the technical work in-house. If you already have graphics people on the payroll, training a few of them in Web design is probably a good investment, and you may find that some of the people working for you in art-related jobs are already doing at least some Web design on the side and will jump at the chance to do more of it.

A smaller company that relies on contractors or freelancers to handle computer work and graphics, may want to keep using contractors or freelancers possibly the same ones it already uses for print graphics production when moving onto the Web.

Businesses too small to have either their own in-house computer people or steady relationships with outside computer contractors or graphics designers should probably avoid making their own database-driven, dynamic Web sites as long as they can. A cleverly-designed static site can provide plenty of functionality at little cost, and while maintaining it can be somewhat tedious, that maintenance can be performed by properly-trained clerical workers who cost much less to employ than programmers or systems administrators. The point at which it becomes cost-effective to switch from a static site to a database-driven one is an individual business decision. The "over 100 products" rule is only a rough guide but, in general, switching too late is better than switching too soon. An ecommerce business that is so profitable that it needs upgrading is better than one with a sophisticated infrastructure behind it that is losing money because it has a complex, expensive Web site, but isn't attracting many customers.