IMO, unix/perl is the direction you want if, as you said, you don't want
the current solution to be a dead end. the NT database systems i've
seen have had scaling problems when they tried to grow, and the
programming is frankly a bitch.
my primary argument for unix over NT is unscheduled downtime, aka:
crashes, glitches, and system hangs. the stats i've seen (and have
heard verified by the people who use NT in production) show that under
load, NT systems run about 3-5% USD. that's roughly an hour down, per
machine, per day. worst of all, from my point of view, there's not much
correlation between uptime and crashing. you can't drop the crash rate
by shutting the machines down and rebooting periodically (converting
unscheduled downtime to scheduled downtime). reboot an NT server, put
it back into production, and five minutes later you can see the blue
screen of "why didn't i go with another OS?". unix systems can grow
unstable over time, but they tend to be more deterministic about it.
if you reboot once a week, you start over fresh, and it's perfectly
feasible to run a unix network with zero (or at least vanishingly small)
USD.
in general terms, go SQL for the database interaction if you want
scalability or flexibility for the future. it's always tempting to do
short-term hacks that get the job done now, but experience has taught me
that they just have to be pulled out and done correctly later.
for the database engine itself, i'd suggest that you add postgres to
your list of options. it's an SQL-compliant engine from U Cal
Berkeley, and its basic technology which was sold to Informix as the
basis of their commercial product. it's quite robust, and free.
Oracle is an incredible product, but probably has a thousand times as
power as you really need. it's the DB engine of choice when you have a
few hundred million items that have to be placed among several hundred
tables for speed, but for civilians it's like using a terawatt laser to
edge a lawn.
using apache for the webserver is nearly a given. it's an exceptional
product, and is probably the best-supported webserver on the 'net. i
believe there are modules which can be compiled into it which will query
a postgres server directly, making your DB lookups about as simple as
SSI calls. if i'm mistaken on that, i know that there's a PHP module
for apache that supports postgres queries, because i have servers
running all three in my network here.
putting the webserver and the database engine on the same machine is
possible, but causes scaling problems if & when you want to grow. DB
engines are fairly CPU and drive intensive, which makes them bad
roommates for other client-server systems. they also tend to be a bit
fastidious about their environment.. running a database of any size
involves complex interactions between file storage and memory buffers,
and it's best not to risk jogging the engine's elbow as it keeps
everything in synch.
granted, the odds of a glitch taking out the database are fairly low,
but on today's computers "one in a billion" happens about every five
seconds. besides, the consequences of a crash are rotten enough that
almost any form of prevention is better. once you've tried rebuilding
a crashed database by hand, burning joss sticks and waving dead chickens
seems downright reasonable.
mike stone <[EMAIL PROTECTED]> 'net geek..
been there, done that, have network, will travel.
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
