Re: Justifying a PG over MySQL approach to a project

I was wondering...

In head-to-head comparisons, do DBs get stree tested, not only in terms of performance, but in terms of corruptions, down time, recovery time, lost data, etc... .?

I've heard it said that MySQL is superior to MySQL in this regard. But if this were stated in an article from a 3rd party or something, THAT would make an impact on mgmt.

On a different note...

Other projects in the group use MySQL. In the past, the risky decision was made to put the highly volitile tables of these other users in the same MySQL database as the project critical data tables (the ones I just rewrote into PG). Of course, I moved the critical tables out to a separate DB and let them play in a sandbox (MySQL, PG, SQLite,... whatever they want) But one criticism I expect to have to deal with has to do with their apps no longer being able to simply join into the project critical tables for queries anymore (they'l no longer be in the sane DB, and in fact, on PG as opposed to MySQL).

They have ways to cope with this. Since they all code in perl/DBI, they could simpy open handles to the 2 DBs. Or there's an op sys level app out there that they could use to get the same data. But I was thinking of something that would retain their ability to "join" into that data.

At first, I was thinking that I'd just write a stored procedure in MySQL that runs a perl script that opens the PG DB, gets metadata for the view that has the data they want, plus the data in the view, then create a temp table in MySQL which = the view and load it up with data. But I just found out yesterday that MySQL does not support stored procedures written in other languages (like PG supports perl, tcl, python...). So my fallback is to write the perl script in a perl module where it accepts as input a DBI handle to the MySQL DB. With the MySQL DB handle in hand, the perl script would then attach to the PG DB, get the metadata for the view, create the view in MySQL as a temp table, then populate it. This view has <5,000 records in it, so it's realistic to do in real time. The one thing I lose with this is scripting language independence (it's a sub in a perl module, so you can only use it from perl).

If anyone can brainstorm a better solution to this I'm all ears (eyes, whatever...)?

-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org [mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Erik Jones
Sent: Monday, December 21, 2009 12:56 PM
To: pgsql-general(at)postgresql(dot)org List
Subject: Re: [GENERAL] Justifying a PG over MySQL approach to a project

On Dec 21, 2009, at 8:44 AM, Scott Ribe wrote:

> Well, the fact that Monty secretly tried to persuade the EC toward forcing
> Oracle to release MySQL under a license other than the GPL, while lying &
> denying that in public, really shouldn't be considered a plus for MySQL, I
> would think ;-)
>
> Seriously, founder & current owner engaged in political intrigue over
> licensing? Try running that by a risk-averse manager!

I was literally just discussing this situation with our other DBA at work. Monty, who *chose* the GPL for the open source end of their inane dual-licensing scheme, and Stallman, who *wrote* the damn thing, are trying to get the EU to force Oracle to change the open source end of the license to something more permissive, arguing that the viral nature of the GPL will force companies that release proprietary products that use MySQL to buy commercial licenses from Oracle which is exacly why they (MySQL AB) set things up in that manner when Monty owned the company. It seems to me that Monty & co. wanted to have their cake and eat it too and are now crying because Oracle wants to buy the recipe.

If you're company releases any kind of proprietary software then that situation alone sounds like a good business reason to me not to be looking at MySQL right now.

Erik Jones, Database Administrator
Engine Yard
Support, Scalability, Reliability
866.518.9273 x 260
Location: US/Pacific
IRC: mage2k