Re: [PHP-DB] Re: MySql or postgre? From: Bob Hall (bobhall <email protected>)
Date: 11/28/00

>On Mon, Nov 27, 2000 at 10:03:35PM -0400, Bob Hall wrote:
>
>[ ... ]
>
> > harder to learn. Earlier versions had a reputation for corrupting
> > tables every few months under steady use. Whether this problem
> > continues in the current version, I haven't heard.
>
>ya, this can be annoying. we saw it with 6.5.x, and after much farting
>around, discovered that if we made *absolutely sure* that no INSERTs or
>UPDATEs would cause a row to be greater than 8192 bytes in size, the
>corruption disappeared. yes, it'd be nice to not have to check, but at
>least we can have a stable db. in theory the pgsql backend should be
>checking this. i guess someone forgot :-)
>
>i am informed that 7.0.x has fixed this bug, and we're in the migration
>process from 6.5.x now. 7.1.x is looking extremely good - no more 8k
>row limit.
>
>if anyone has seen corruption in more recent pgsql, i'd certainly like
>to hear about it.

If someone has *not* seen corruption in pgsql 7.1 under steady, hard
use, I'd like to hear about it. If it has reached the point where I
can consider recommending it to clients, I'd certainly like to know
about it.

> > The question is not whether one is better or not, but what you want
> > to do. If you want a draught animal that can haul anything, go with
> > PostgreSQL. If you want a race horse that goes fast around specific
> > types of tracks, pick MySQL.
>
>one question is (at least in the web world, which is what this list is
>about): how many sites *don't* really need stuff like transaction
>support? sure, you can play games and do tricky stuff but in the end,
>its a lot nicer to just be able to go 'begin; ...; ...; end; commit;'

I've used MySQL in commercial apps where transaction support was
completely irrelevant. I'm working on a proposal right now where I'm
going to recommend a MySQL backend. The client doesn't need
transactions, and doesn't need updates or deletes under high
concurrency. There are many commercial applications where MySQL is
perfectly suited. That's not to say that MySQL is never misapplied by
people who don't understand databases.

>mysql will certainly be interesting once the transaction support is
>tagged "stable".
>
>[ ... ]
>
> > difference will become much smaller. Second parties are adding
> > transactions and row level locking to the basic MySQL package,
>
>this worries me a bit. i don't mean to deride the developers of mysql
>or the transaction code, but it seems to me that transactions are fairly
>integral to a rdbms, and not the sort of thing you can just "add on"?

I agree, and the developers seem to be having trouble getting MaxSQL
(MySQL with transactions) into stable form. People who have compiled
the transaction version say it is noticably slower than MySQL. I'm
glad that progress is slow, since that increases the probability that
the end product will be right. Notice that I pointed out that MySQL
with transactions isn't even gama ware yet.

>like a car. you can't start with just seats and wheels, you need a
>chassis first.
>
> > For PostgreSQL, the development team is ironing out the remaining
> > kinks and turning it into real competition for the commercial DBMSs.
>
>while it may lack some of the features of the commercial DBMSs, i think
>it already is very real competition. i'd certainly choose pg over
>oracle any day of the week. i find it far more user- and admin-friendly,
>and i'm sure i'm not alone.

If they've solved the corruption problem, it is competition.

Bob Hall

Know thyself? Absurd direction!
Bubbles bear no introspection. -Khushhal Khan Khatak 

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: php-db-unsubscribe <email protected>
For additional commands, e-mail: php-db-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>