Alain TESIO wrote:
> > Subsidiary question : why is mySQL excluded from RDBMS
> > comparison on postgress www site ?
I believe it's fairly stated: mySQL is not an RDBMS, so it
is not listed. A similar question: Why is Filemaker excluded?
FoxPro?
They all have a speedy, flat file, structure, glued together
in such a way that relational-like interactions are available.
> Maybe because it's much faster ;)
The speed of not having some relational feature that you
desparately need, but is not availabe, is approximately
zero. :-)
I like it for simple structures, simple db's, but as soon as
you're trying to manage 30-40 tables, mySQL starts to get
in its own way. For running SQL to a flat db? It's much
better than PostgreSQL. 200 Tables? Don't even think about
it, get an RDBMS.
> Sure, MySQL doesn't support transactions, rollbacks, ...
Foreign keys...
> I've compared both engines and MySQL is much faster.
Yup. Different design goals.
> However I'll need transaction to ensure reliability
> for the database updates. I've thought at using PostgreSQL
> for updates, and MySQL for select, the database being
> dumped from PostgreSQL and reloaded into MySQL every
> night. Probably with specific queries and scripts rather
> than a dump to get a MySQL-compliant dump file.
> Has anyone an experience about a similar solution ?
We are in the midst of nightly dumps of mySQL -> PostgreSQL,
in order to gradually migrate to a more robust solution...
however, it seems like your proposed idea _could_ work, with
some decent scripting. Fast for simple scans, too...
basically, you'd need text dumps, which are then re-wrapped
to mySQL-friendly insert (or whatever) statements.
HTH,
-Bop
