Re: [cgiapp] "Best free DB for a web-based Perl app" response results...

["Nathan L. Walls" <suppressed>]

Yes, I'm cherry picking, but some points I wanted to touch on or ask  
about.

On Dec 1, 2005, at 2:40 PM, Cees Hek wrote:

> On 12/1/05, Jesse Erlbaum <suppressed> wrote:

[snip]

> There are <tonnes> of other annoyances with MySQL but I'll only list a
> couple that 'really' annoy me:
> - the first timestamp field in any table is always updated on every  
> UPDATE
> - 0000-00-00 is a valid date in MySQL
> - 2005-02-30 is a valid date in MySQL
> - insert NULL into a NOT NULL column and MySQL will give it a  
> default value
> - overflowing data is truncated instead of returning an error

Some of this sort of thing bit us when we started using MySQL over  
PostgreSQL for newer applications. I have been made aware, however,  
of a new configuration option in Version 5.0 that removes some of  
this "helpfulness"

http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html

[snip]

> >   1. Simple
> Yes (but not always obvious in what it does)
>
> >   2. Reliable
> Reliable in that MySQL rarely crashes.  But not reliable when it comes
> to data integrity.  The fact that MySQL has some of the best crash
> recovery tools available should be a sign.  I still get table
> corruption happening regularly on heavily used tables (Although almost
> all of the time MySQL is able to recover those tables with the caveat
> that I can never be sure that nothing was deleted in the cleanup).

If you got into trouble with data corruption and an RDBMS and you  
didn't have recovery tools, I'd see being upset. But to "punish"  
someone for having good tools? I think that's unfair.

[snip]

> PostgreSQL is fast, rock solid and works out of the box.  I have never
> had any issues with disappearing data, or table corruption with
> postgres.  I have never had postgres crash on me.  I rarely have to
> read the postgres manual to figure out how to do something.  It has a
> fantastic query optimizer and very useful explain output.  And it has
> a huge amount of options when it comes to complex queries.

I will agree on the explain output. MySQL's takes a little getting  
used to be useful.

> On the other hand, I still suffer from table corruption with MySQL.
> It still munges my data at a whim just so it doesn't have to throw an
> exception.  I still have to do things with temporary tables that
> should be done with a sub-select (we don't run mysql 5 yet, since it
> is too new for me).

Data corruption? In InnoDB tables? Are there general circumstances  
when that occurs. I'm genuinely curious on that one.

Thanks,

Nathan

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
             http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed