Re[2]: [PHP-DB] Re: MySql or postgre? From: Alexey Borzov (borz_off <email protected>)
Date: 11/28/00

Greetings, Bob!

At 28.11.2000, 18:20, you wrote:
>>BH> harder to learn. Earlier versions had a reputation for corrupting
>>BH> tables every few months under steady use. Whether this problem
>>BH> continues in the current version, I haven't heard.
>> 7.0.* don't corrupt anything anymore...
BH> Glad to hear it. Can you be more specific?
::shrug::
Well, there was that specific point about not checking tuples which
are too long. I've recently tried to load a DB dump from MySQL where some
of the tuples were longer than 8kb into Pg 7.0.3... It complained,
aborted transaction and didn't even try to corrupt anything...

>>besides,
>>its documentation is far more adequate than MySQL's.
BH> I don't have any problem getting excellent documentation for MySQL.
::shrug::
Yup, "Reasons NOT to use foreign keys" is my all-time favourite, too.
I've already raised that point on this list, I believe...

>> The problem is that MySQL's target auditory is the same as (f.e.)
>>M$ Access' - people who wanna use 'nifty database thingies' without investing
>>too much time into learning.

BH> No sir, that's not the target audience. The target market is people
BH> who only need a subset of the capabilities that Oracle offers.
    Let's be a lil' wee bit more honest: a very small subset of what
SQL standard offers...
    The most annoying part of MySQL is that misapplied 'SQL' part in its
name...

>> I'm afraid, MySQL is just that - a spherical horse in vacuum. It
>>is quite fast while performing its own benchmarks, but may choke on
>>realworld tasks.

BH> It will choke on realworld tasks if you use if for tasks it wasn't
BH> designed to perform. It does very well with realworld tasks it was
BH> designed to perform. Its benchmarks are intended to highlight its
BH> ability to perform the tasks it was designed to perform.
    Seems we have reached a consensus. Original poster has to review
MySQL benchmarks and decide, will his applications be limited to what
is done in them, or will he be doing something more complex.

>> Well, a metaphor once again:
>> "Second parties adding transactions and row-level locking to the
>>RDBMS" is like "Second parties are adding 3D engine to Quake". It means one
>>thing: program's own developers are INCOMPETENT.

BH> Not in the least. It means outside developers want to use the
BH> software for purposes the original developers didn't have in mind.
BH> Since it is open source, they can do that. The fact that outside
BH> developers consider MySQL a good base for further development is
BH> testament to the original developers competence.
::shrug::
Transactions are a vital part of RDBMS. If its developers fail to
understand this (or fail to implement them) - then... 

-- 
Yours, Alexey V. Borzov, Webmaster of RDW

-- 
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>