Re: Justifying a PG over MySQL approach to a project - Mailing list pgsql-general

I was wondering...

In head-to-head comparisons, do DBs get stree tested, not only in terms of performance, but in terms of corruptions,
downtime, 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
partyor 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
theseother 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
theywant) But one criticism I expect to have to deal with has to do with their apps no longer being able to simply join
intothe project critical tables for queries anymore (they'l no longer be in the sane DB, and in fact, on PG as opposed
toMySQL).   

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'san op sys level app out there that they could use to get the same data.  But I was thinking of something that
wouldretain 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,
getsmetadata 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
writtenin other languages (like PG supports perl, tcl, python...).  So my fallback is to write the perl script in a
perlmodule where it accepts as input a DBI handle to the MySQL DB.  With the MySQL DB handle in hand, the perl script
wouldthen 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
scriptinglanguage 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@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Erik Jones
Sent: Monday, December 21, 2009 12:56 PM
To: pgsql-general@postgresql.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
sourceend of their inane dual-licensing scheme, and Stallman, who *wrote* the damn thing, are trying to get the EU to
forceOracle to change the open source end of the license to something more permissive, arguing that the viral nature of
theGPL will force companies that release proprietary products that use MySQL to buy commercial licenses from Oracle
whichis 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
reasonto 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






--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general