Choosing DBMS and architecture for ecommerce website

[Alex_Bxl]

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 lot

[Michael Peppler]

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
--
Michael Peppler Data Migrations, Inc.
mp******@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

[Ed prochak]

"Michael Peppler" <mp******@peppler.org> wrote in message news:<pa****************************@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.