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