MySQL comparison

MySQL comparison

Post by Bruce Momji » Wed, 27 Jun 2001 01:14:57



For people interesting in MySQL's status, here is a posting from the
recent Red Hat/Slashdot discussion.  It seems to lay things out pretty
clearly.

---------------------------------------------------------------------------

Remaining SQL92 issues: subselects in SELECT, subselects in FROM (also
called projections), subselects in WHERE. Each can be thought of as a
seperate implementation issue. Views. Updateable views. Foreign keys.
Constraints, in particular referential integrity constriants. Required
transactions - this is part of every SQL standard, it's a base
assumption. SELECT INTO table. Temp tables. Domains. Stored procedures
and triggers aren't standardized, but every major DB has them, and
they're demanded out in the real world -- add them to the list.

After adding all the above, MySQL will need some serious (read:
light-years of) development on their query analyzer. MySQL does well on
simple selects but performs notably slow on complex queries. Which is
hardly a surprise given their assumptions, design goals, and evangelism.

InnoDB needs more testing, and it needs to continue to grow. I have full
faith in Heikki Turri's skill.

I cannot say the same for the other MySQL AB developers. They have spent
the last few years stonewalling efforts to turn MySQL into a real DB.
They proclaimed that transactions were bad, table locks were as fine
grained as you ever needed, constraints should be handled by the client
application, and that stored procedures existed because other vendors
couldn't write fast SQL parsers (thus showing a failure to understand
the difference between declarative and procedural programming). Now,
demands from their larger customers, plus products from people like
Heikki, appear to be forcing MySQL AB forwards towards ACID compliance.
So, no, I do not trust MySQL AB to implement these things quickly and
effectively.

If you read their TODOs, you can see most of this stuff in targeted for
4.1. That's 2 major revs away. What will Postgres be doing in that time?

--
Bruce Momjian                        |  http://candle.pha.pa.us

+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------

 
 
 

MySQL comparison

Post by Daniel ?ker » Wed, 27 Jun 2001 02:05:47


Quote:> What will Postgres be doing in that time?

Eager data replication with no performance penalty? *haa-haa* ;)

Daniel ?kerud

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://www.postgresql.org/search.mpl

 
 
 

MySQL comparison

Post by Mike Masca » Wed, 27 Jun 2001 03:40:15



> > What will Postgres be doing in that time?

> Eager data replication with no performance penalty? *haa-haa* ;)

> Daniel ?kerud

Of course, fgrep is even faster! ;-)

Mike Mascari

---------------------------(end of broadcast)---------------------------

 
 
 

1. RFC: PostgreSQL and MySQL comparison.

Greetings!

    Well, I suppose everyone on this list will agree that Postgres is
superior over MySQL (or else they would have joined MySQL mailing list
*chuckle*). So I would just note one area where MySQL is considerably
stronger: PR.

    Every fart of MySQL developers gets noticed by high profile sites
(change of logo, "NASA switches from Oracle to MySQL" - remember this
one?, addition of Perl SPs, etc). I even remember "Gemini
table type" announcement on Slashdot when this table type was complete
vapourware. Besides, every comparison between PgSQL and MySQL draws
attention from MySQL employees and volunteer trolls (check talkbacks
on PHPBuilder, for example).

    I suppose PgSQL has to take a more active stance as well. Consider
"M$ vs Linux debates". Of course here both projects are Open Source so
the discussion should not be as heated... But I do think that
the statements in
http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html
should NOT go unanswered.

    So, I propose the (semi-)official featureset comparison, but from
Postgres users' POV. With a healthy dose of FUD as well, it is time for MySQL
folks to taste their own medicine...

    Things that, IMHO, should go into this comparison:
1. MySQL does not satisfy the semi-official definition of RDBMS -
"Codd's 12 rules", as it is in complete violation of rules 4 and 6
2. MySQL is not SQL-compliant as views and subselects are required by
entry-level SQL92 spec (I may be mistaken here, 'cause I have only the
Russian translation of Gruber's "SQL Instant Reference")
3. MySQL did not have a major release to fix their shortcomings
in several years, while Postgres evolves constantly. Moreover,
according to MySQL's "roadmap" the most requested features are pushed
back from mythical "4.0" to even more mythical "4.1" and "4.2"
4. It is very difficult to port to or from MySQL, 'cause the logic
that is usually incapsulated in DB should be rewritten in application.

    Of course I don't think this should go into PgSQL manual, it is
definitely not the place for such rants, but it should be published on
some of "official" PgSQL sites. And then submitted to /. and such. :]

    Well, I *can* take up this "project", if it will be approved here,
but must admit that the results should br reviewed by someone for whom
English is a native language. :]

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

2. Using permanent connections with Progress

3. Query Problem to a SQL 6.5 Server

4. a draft: PgSQL/MySQL comparison

5. Throwing a recordset at a report

6. Feature comparison between Postgresql, Oracle and Mysql ?

7. Getting key value with an insert and using it in another.

8. PostgreSQL in Comparison to mySQL

9. Oracle vs PostgreSQL vs MySQL vs mSQL : COMPARISON

10. Comparison of MySQL and MS SQL

11. Feature comparison between Postgresql, Oracle and Mysql ?

12. ANN: ImportER MySQL-reverse engineer MySQL databases