Choosing DBMS and architecture for ecommerce website

Hi to all

I have to choose a DBMS and a database architecture for an Ebay like
website about to be launched.

The company wants to use a web hosting service and not host the
database on dedicated servers at the office.

The database will contain web-only information and lots of back end
information that is not really needed to be stored on the web host.

I'm wondering how to design that part, should I store all information
on the web host only ? miror that DB every evening on some local DB
server to be able to use the data without eating up lots of bandwith ?
separate the database in 2 parts ? how to sync and assure integrity
then ? having a local DB will also mean the company will have to pay a
licence for the DBMS ...

What DBMS should I pick considering that the database will have to
hold at least 1 million products to sale (eBay like) and all the
information that goes with it. I thought any DBMS weaker than SQL
Server or Sybase or Oracle will not be enough. What do you think ?

Thanks a lot, hope I have made myself clear enough

P.S. I would really like to get lots of different points of view. I
think I'll use Sybase after all, so I wonder if that'sa good choice
and I still want to know your thoughts about the 2 or 1 DB design
(separate Web & Billing information for example, or leave all the info
in the hosted database, what techniques to use to keep the integrity
and to have the latest information in-house)... Thanks a lotOn Mon, 03 Nov 2003 07:08:07 -0800, Alex_Bxl wrote:

> I'm wondering how to design that part, should I store all information
> on the web host only ? miror that DB every evening on some local DB
> server to be able to use the data without eating up lots of bandwith ?
> separate the database in 2 parts ? how to sync and assure integrity
> then ? having a local DB will also mean the company will have to pay a
> licence for the DBMS ...

I'd use Sybase, and I'd use replication server to move data from the
production server (in co-location facility) to the reporting server (in
the office).

But you can do similar things with Oracle, MS-SQL, etc., although I'd
personally stay away from MS-SQL due to its being Microsoft-centric (i.e.
can't scale beyond Intel/Windows type machines)

Michael
--
Michael Peppler Data Migrations, Inc.
mpeppler@.peppler.org http://www.mbay.net/~mpeppler
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.mbay.net/~mpeppler/resume.html|||"Michael Peppler" <mpeppler@.peppler.org> wrote in message news:<pan.2003.11.03.15.33.00.222843@.peppler.org>...
> On Mon, 03 Nov 2003 07:08:07 -0800, Alex_Bxl wrote:
> > I'm wondering how to design that part, should I store all information
> > on the web host only ? miror that DB every evening on some local DB
> > server to be able to use the data without eating up lots of bandwith ?
> > separate the database in 2 parts ? how to sync and assure integrity
> > then ? having a local DB will also mean the company will have to pay a
> > licence for the DBMS ...
> I'd use Sybase, and I'd use replication server to move data from the
> production server (in co-location facility) to the reporting server (in
> the office).
> But you can do similar things with Oracle, MS-SQL, etc., although I'd
> personally stay away from MS-SQL due to its being Microsoft-centric (i.e.
> can't scale beyond Intel/Windows type machines)
> Michael

Dual DB's aren't really necessary.

Points in favor of 2 DB's
*its standard approach Production and Development DB's
*large reports don't hog resources from live interactions.
*new developments/data are staged in development first, in a secure,
isolated environment.

points in favor of 1 DB
*if its accessable from the WEB then developers can work there too.
(schema isolation should be as good as DB isolation)
*web access means you know when the site goes down.

I've seen both.