Re[2]: [PHP-DB] Re: MySql or postgre?

From: Date: Tue, 28 Nov 2000 15:49:59 +0000
Subject: Re[2]: [PHP-DB] Re: MySql or postgre?
References: 1 2 3 4  Groups: php.db 
Request: Send a blank email to php-db+get-4811@lists.php.net to get a copy of this message
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

« previous php.db (#4811) next »