Oracle Woe's - Pam Issue?

[Craig White]

On Tue, 2007-12-11 at 15:57 -0700, Bryan O'Neal wrote:
>  >… However that depends on what you would like to accomplish.
> 
>  
> 
> I know that eventually I will be handling thousands of transactions a
> minuet (estimated ½ million transactions per day in less then 18
> months) from a slue of vded’ed front end Apache Webs Servers attached
> to another group of vded’ed Tomcat Servers running some in house Java.
> I am worried that MySQL is not going to be able to handle the load.  I
> was going to start with Oracle XE because the move up to larger
> products is (supposedly) as easy as installing a license.
> 
>  
> 
> Our predicted growth cycle is fairly rapid until we get close to our
> predicted saturation rate, and some tables are likely to hit 100-200
> million records in very short order, so I need a strong DB to handle
> the load.  The problem is I am trying to be very frugal until we see
> positive, stable, cash flow, which will not be until the middle to end
> of next year.
----
Oracle seems to be the wrong place to start if you don't already have an
Oracle DBA on line. Too much tweaking and technical hurdles for those
without a foundation.

MySQL is immensely popular because it has a bunch of GUI tools for those
that want to play at being a DBA without actually the foundational
knowledge. There are a bunch of gotchas with MySQL and eventually they
tend to get in the way. Not a bad place to start though.

PostgreSQL is definitely a high performance system and much more
consistent and reliable. While there aren't as many GUI tools as MySQL,
it's a workhorse, easy enough to get around in, has nice built-in tools
and you can sleep at night.

All of the above are going to require considerable knowledge to handle
thousands of transactions a minute.

Most middleware tends to abstract the actual database being used so
migration shouldn't be the biggest hurdle.

Probably the best idea is to start with something you can actually use,
perhaps tune for performance, backup and otherwise maintain and adjust
as necessary.

Craig