20 September 2005

YourSQL not mine

I have been a PostgreSQL user for quite some time and it hasn't failed me on most of the basic and advance features that I expect to get from it, whether I write client software in Java or in C, the results are consistent. Before then, I have a "weak" argument that MySQL is weak. Because I only scratched the surface of it and didn't do a lot of thorough testing. This MySQL, by default, has failed on a lot of things compared to Postgresql point by point even on some minor things. Some of the things I noticed are:


  • Lousy way of granting permissions

  • The autocommit functionality can break the most generic JDBC code that is supposed to support multiple databases

  • Tables are case-sensitive, unless you're a diehard Windows genius, you're not going to notice this.

  • The interactive command-line interface is so crude. It's nothing compares to PostgreSQL

  • So some silly asshats will ask me "Why would you use a CLI when there's a lot of GUI tools for MySQL?", even that sucks too. And what if the only available thing to you is an SSH access without X? Then you're dead in the middle.

  • The PreparedStatement.executeUpdate() does not return the right value for the rows affected, I am wondering what's the big deal why this thing can't be fixed since Postgresql, Oracle and other "production-grade" databases can handle it. Just simply returning the right value is very important for debugging and information purposes.


  • These are just a few things that I can remember after my fury died out. I am not going to the argument of "you don't know shit" or "read the fucking manual" stuff. By all virtues of a good database, out of the box, everything must work fine, just like Postgresql or even Thunderbird. In the end, I have deduced so far, that those who are so in love with this database are merely Windows users, that are writing apps which are even simpler than a candy store application.

8 comments:

Mark Matthews said...

I'm a little confused.

You state the autocommit functionality is broken...how? It's JDBC-compliant.

You state PreparedStatement.executeUpdate() returns the wrong update count...As far as I can tell, it doesn't (and once again, it's JDBC-compliant, and tested for), and it acts the same way as Oracle or PostgreSQL, so I'm confused as to what your compliant is about.

Maybe you're venting, but if you expect anyone to take criticism seriously, you have to be more specific.

What kind of BLOG requires you to have a blog on their system to post comments, btw? (as an example of "venting").

Jared said...

Ok, maybe you're one of those "compliant"-sensitive people. Does being JDBC-compliant ensures quality? You see, the effect is inconsistent it works on your machine while it doesn't worked in mine. Perhaps you did some tweaking and that's what you call compliant. It should work out of the box. Yes autocommit is broken, switch it off programmatically and call Connection.commit() and it will not write anything on the table.


Just like J2EE compliancy, there's a lot of J2EE-compliant application servers out there, are they all good?

Before you vent, do your further testing. And by the way, you already took my criticism seriously by posting here.

Mark Matthews said...

I actually believe that JDBC complaince actually does deliver quality since at the very least it tests the very things you say don't work, and many other dark corners that many implementations of JDBC get wrong at first.

I'd love to see how you're actually trying to test this (maybe you don't know that MySQL uses a default REPEATABLE READ isolation level, which is a common mistake with users new to MySQL?).

I'll leave at that, since it appears you're looking for a flame war, rather than a productive conversation anyway.

Jared said...

REPEATABLE READ Isolation Level? Who cares? I just want to make this "JDBC-compliant" Database work the first time. You got the point? You see? Should that be part of the JDBC-compliancy? Do I need to know about this REPEATABLE bullshit? It is more important to keep the generic SQL skill a developer has rather than mingle on those MySQL-specific things.

The JDBC specs requires only that a driver should comply according to it. But at the performance or operational level, it's a different story altogether. It should work RIGHT the first time.

Rajneesh Garg said...
This comment has been removed by a blog administrator.
Rajneesh Garg said...

I have been using MySQL for quite some time now, and I HAVE NOT FACED 'JDBC-COMPLIANT' ISSUE EVEN ONCE. I have even used MySQL with autoCommit off i.e. commit/rollback the SQL execution manually, and have not faced any issue. May be U faced issue for DB Engine. By default, MySQL provides IMySAM DB Engine. Change it to InnoDB and then see the effect of manual commit/rollback.
There might be some issues in MySQL Administration but then its a DBA's work and not of a developer's. But then same is true for all the DBs whether its Oracle or MySQL. And MySQL is the easyiest of all the DBs to install.
Ofcourse, there is *no harm* in refering to manual once in a while, after all u r in an industry where u have to keep urself updated all the times. OK la :)

Jared said...

Yeah it's ok. It's just MySQL is just too flaky for me.

Richard said...

I couldn't agree more to any side. I have not used posgres but I would have loved to. MySQL does not score negative nor positive either.

The sad thing is, whatever flaws that you might point out with MySQL, it seems to be gaining ground and being championed by the F/OSS-leveraging enterprises (ie IBM). Look at LAMP.

I just hope it is not that too flaky.