Re: taking orders

G'day

> Just a note here:  Just because a cart is database driven does NOT mean
that
> it is going to be slow.  I have designed several sites that contain over
> 15,000 items and the search time for an item (or link to an item) is
almost
> instant.

We use an ASP driven Access database.  We had some trouble with (lack of)
speed.  However, it turned out to be a problem with one of the routers in
the host's data center.  It was replaced and all is well now.  Most pages
only take a few seconds to load (at 49kbps).  The advantage of a database
driven site is in maintenance and search facilities.  It can also make it
easy to show the same product in different categories/on different pages.

I maintain two "gift shop" sites.  One does NOT use a database and has over
200 HTML pages.  Many products appear on more than one page.  Change the
price?  Hmmm.  Which pages can I find this product on. Will I find all of
them.. Change the layout?  Phone number?  Hmm.  200+ pages to change.

The second does use a database.  Many items appear in different categories.
Update the price?  Simple - go to the admin panel, locate the product and
change the price in the database.  DONE - any page that shows the product
will reflect the new price.   Change the layout or phone number?  The
cart-generated pages use a header and footer file.  That's all we need to
change.   And customers can search for any product by keywords.

Oh.  On a non database driven cart, try increasing (or decreasing) the
prices of all products (or a group of products) by 5%.   With a database,
it's relatively simple (one SQL statement could do it in a matter of
seconds).  I shudder to think what it would take on a 5,000 page site that
has all hard-coded HTML..

My $0.02 (Australian) worth
--
Bert Doorn, Web Developer
CIW Associate, IWA Member
www.betterwebdesign.com.au
Fast Loading, User Friendly Websites

HTML: hwg-basics mailing list archives, maintained by Webmasters @ IWA