Re: Re: MySql or postgre?

From: Date: Tue, 28 Nov 2000 16:02:47 +0000
Subject: Re: Re: MySql or postgre?
References: 1 2 3 4  Groups: php.db 
Request: Send a blank email to php-db+get-4813@lists.php.net to get a copy of this message
i've been reading alot about this, and for my needs i think mysql do what i need. i also know oracle, but many many things it does is not needed... at least for now, so i think that i will use mysql insteade of oracle or mysql. i need a simple database. it will be huge but simple. i thank you all for answering my question! ----- Original Message ----- From: "Bob Hall" <bobhall@clark.net> To: <php-db@lists.php.net> Sent: Tuesday, November 28, 2000 3:11 PM Subject: Re: [PHP-DB] Re: MySql or postgre? > >Greetings, Bob! > > > >At 28.11.2000, 12:00, you wrote: > >BH> Whether it's faster or not depends on the environment. For OLTP, > >BH> definitely faster. For churning out web pages, probably not. On the > >BH> down side, PostgreSQL is bigger, more complicated, harder to install, > >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... > > Glad to hear it. Can you be more specific? > > > Postgres is not too hard to learn or install (I've once watched > >people installing Oracle - THAT was an unforgettable experience), > > Yes, I've installed Oracle. > > >besides, > >its documentation is far more adequate than MySQL's. > > I don't have any problem getting excellent documentation for MySQL. > > > 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. > > No sir, that's not the target audience. The target market is people > who only need a subset of the capabilities that Oracle offers. > > >BH> The question is not whether one is better or not, but what you want > >BH> to do. If you want a draught animal that can haul anything, go with > >BH> PostgreSQL. If you want a race horse that goes fast around specific > >BH> types of tracks, pick MySQL. > > There is a good anecdote about race horses... Unfortunately, it is > >long, it is in Russian and I don't want to do its full translation... > > The summary is as follows: a physicist was given a grant to > >solve a scientific problem - which horse will come first in the races? > >After some hard work and spending all the money he was able to solve > >it... Using the model of "a spherical horse in vacuum". > > That's a nice story, but what does it have to do with this > discussion? I'm not trying to predict the winner, I'm just pointing > out where the two RDBMSs have strengths. MySQL is a specialized RDBMS > that performs well in some areas. PostgreSQL is a more general RDBMS > that tries to cover more ground. The original poster wanted to know > which was best. If I had answered that one was better than the other, > then you could accuse me of using the 'spherical horse in a vacuum' > model. But I haven't said that. > > > 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. > > It will choke on realworld tasks if you use if for tasks it wasn't > designed to perform. It does very well with realworld tasks it was > designed to perform. Its benchmarks are intended to highlight its > ability to perform the tasks it was designed to perform. > > > >>how about sql... are there any lacks on both of the data bases? > > > >BH> At the moment, PostgreSQL has the edge (e.g. subqueries, set > >BH> functions like UNION). > > > >BH> MySQL is adding SQL functionality, so in the next few months the > >BH> difference will become much smaller. Second parties are adding > >BH> transactions and row level locking to the basic MySQL package, > >BH> although currently the first is not yet gamma ware and the second is > >BH> vapor ware. If these ever become reality, they will allow MySQL to > >BH> function in an OLTP environment. Basically though, I think it's > >BH> always going to be a niche database, although in a very large niche. > > 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. > > Not in the least. It means outside developers want to use the > software for purposes the original developers didn't have in mind. > Since it is open source, they can do that. The fact that outside > developers consider MySQL a good base for further development is > testament to the original developers competence. > > Bob Hall > > 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@lists.php.net > For additional commands, e-mail: php-db-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > >

« previous php.db (#4813) next »