Oracle Woe's - Pam Issue?

[Bryan O'Neal]

It's my nature to worry about problems that haven't happened yet.  After
all just because your paranoid doesn't mean their not out to get you ;)
But seriously I like to have things mapped out and tested well in
advance.  If there are two paths you can go by, I like to take both
paths and see which one goes further.  That said, I am still willing to
fight with Oracle, but not as much as I have been.  I will be discussing
with the development team on Friday, and will highly suggest we change
our DB out for My/PosetgreSQL and then just take that road as far as it
will go while working down the oracle path.

-----Original Message-----
From: plug-discuss-bounces at lists.plug.phoenix.az.us
[mailto:plug-discuss-bounces at lists.plug.phoenix.az.us] On Behalf Of
Micah DesJardins
Sent: Wednesday, December 12, 2007 1:34 PM
To: Main PLUG discussion list
Subject: Re: Oracle Woe's - Pam Issue?

Right now I think you're worrying about problems that haven't happened
yet.  MySQL is pretty robust for what it does.  Google uses it for a lot
of internal applications stuff and the architecture of MySQL is
improving all the time.  Personally I prefer PostgreSQL  I think it's
cleaner and it makes "more sense" to me.  Yeah, it's had a reputation as
a bit of a dog but if you haven't looked at Postgres 8 benchmarks you
owe it to yourself to see how PostgreSQL is doing now that the code base
is growing up.  A lot of time and energy is now going into optimizing
performance these days and it has made a real difference.

If you want to be blunt about it, given near infinite resources and
significant database complexity, neither MySQL nor PostgreSQL can touch
Oracle.  However, given finite resources and reasonably simple DB
structure with lots of brief OLTP queries instead of huge long linear
ones, MySQL and PostgreSQL can perform fairly close to on par with
Oracle but all talk about database speed needs to be prefaced with a
caveat that your DB structure and code, your hardware and storage
subsystems and how you have tweaked your chosen DB for performance for
YOUR application will all play a more significant role in your overall
application/transaction speed than which database you chose to begin
with.

For a mere "thousands of transactions per minute" any of the discussed
databases will work depending on how complex said transaction is.  My
advice is to write the best SQL you can that as is as close to ANSI
standards as possible (See Joe Celko's excellent books on this subject
for more info), pick one or the other of the free options (I'd go with
PostgreSQL for constraints and foreign keys alone but hey that's MY
preference and comfort zone go with what feels right to you) with the
understanding that if this really takes off, you'll be planning a
migration to Oracle (which happens all the time) if you find yourself in
a situation where the database you started with is now underperforming.
Just make sure it really is the DB software that is causing your
limitations, not your hardware, storage, or your code (or any number of
middleware solutions for ORM) that is the choke point.

Good luck!

Micah
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss