Databases

[Steve Lane]

matthew_heusser at mcgraw-hill.com wrote:
> 
> >our databases contain data for websites
> 
> That's what I was trying to get at.  If you use the
> web to transmit data, hurrah for you.  You can use
> any of a wide selection of databases to store
> information.
> 
> But, what if you have to transmit > 500MB per user,
> and the data changes monthly?  What if more than 50%
> of your customer base has a 56K modem or slower?
> 25% of your customers don't even have a web connection?
> 
> Well ... then a desktop application might make more
> sense than a web-based app.

well certainly if your customers can't access the
web (which sounds bizarre to me, but whatever),
you are forced to make a non-web app.

i don't understand why "data changes monthly" would
favor a database-per-customer application.

and "transmit > 500MB per user" could mean anything
at all, depending on if that's >500 Mb required to
be transferred in 1 minute, 1 hour, 1 day, etc.

> So, if you're shipping a desktop application, then
> you probably want a database to store the data ...
> and you begin to run into issues of size/price/speed.
> 
> And my previous emails, hopefully, begin to make
> sense.

i guess.  it sure took enough of them to get to
your main point, which i guess is that each
customer has to have their own database copy
running on their machine.

for that case, why not try one of the DBI modules
that don't require a server?  yes, this requires
a Perl install on the user's machine, which i'll
bet is a solved problem.

> Make more sense?  See why 1 database per customer
> is a bigger deal than 1 database at all?

absolutely not.  it's a different deal, not a
"bigger" deal.
--
Steve Lane <sml at zfx.com>