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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss