Re: Need database/architecture recommendation

[Quoted] Maggie, this a hard question to answer without considering transaction volume, number of inventory items, and other factors unique to your situation. You should also consider commercially available "storefront" services and software.

If your inventory item count is beyond trivial (more than 100 items) or your customer base is greater than 200-300 then you should consider using a seperate database server and not running the database on the web server machine. These are guestimates since I dont know your circumstances very well.

You may also want to consider alternatives to scripting as scripts may not be the most responsive way to handle high volumes of transactions, although many scripting solutions can be made to deliver good response. This decision also required a better understanding of your situation.

Security, maintining customer profiles, and system administration all require that you give some thought to how the database is accessed and there are alternatives you should consider. There is no "best", there are mearly alternatives which fit different needs.

Hope this provides enough confus...um, a starting point for your thinking.. Cliff

Maggie wrote:

> I would like to provide an online ordering system - running scripts or
> queries to a database on our server to provide real-time product
> information (pricing, #in stock, etc...). I am looking for advice on
> selecting the architecture of our system - what database formats
> (msaccess, flat file / ASP, MySQL & PHP) are the most recommended? What
> architecture would you recommend?
>
> I am only familiar with running flat files/Perl [UNIX],
> MSAccess(.mdb)/ASP [NT], and MySql/PHP [UNIX]. I prefer a system that
> can run on Unix and not NT.
>
> I'm also concerned that the database stay out of the hands of my
> competitors. What would you recommend on implementation of security?
> Scripts should access the database via?
>
> Maggie
Received on Thu Sep 28 2000 - 17:47:03 CEST