Re: Re: PostgreSQL versus MySQL

Doug, There's something wrong here. This is the internet, we're disagreeing, but we're not flaming each other. If we keep this up, they'll revoke all our software licenses because of our noncompliant behavior.

Hi Bob! That would make a very interesting study. Attempting to come up with a modern definition of RDBMS. Of course, it would be only an academic exercise...but it would be a fascinating paper if any youngsters reading this from a university dorm room or computer lab would like to tackle it.

It's too late. Everyone has their own definition of RDBMS, which they aren't going to give up. :)

Yes, the SQL standard is a moving target. But so are the likes of COBOL and FORTRAN. So all one can do is attempt to produce a product that at least attempts to conform somewhat to some published version of the standard. It is true that no product adheres perfectly to ANSI SQL standards. I believe that that's primarily because, as it exists, SQL is an incomplete and underdefined language. However, some products appear to be more in compliance than others. But I offer up my pet peeve (MySQL's bastardization of LIKE and the recent addition of the BINARY keyword instead of fixing the problem) as an example of MySQL's blatant non-conformance. There are examples in PostgreSQL's history (which indeed has had a turbulent past) of similar things, but they seem to try with every release to bring themselves more in conformance with either ANSI's published standard or at least the generally accepted implementation of what ANSI has published when the standard is unclear. MySQL just complicates an already bizarre language with even more bizarre constructs (BINARY is a recent example).

From Paul's book: "BINARY causes number-to-string conversion." It may not comply with the letter of the SQL standards, but it certainly complies with the spirit; it's completely non-intuitive!

I would tend to agree with THH that if MySQL is a database management system it should offer up more than just their SQL-like front end to a bunch of indexed disk files. I've read their site. (I like their site and their documentation better than PostgreSQL's site and documentation, by the way.) Their excuse for not conforming to SQL standards and for not implementing important features is that they would slow it down unnecessarily. Two things about that: * I do not think things like triggers and transactions are unnecessary, and * According to recent reports, PostgreSQL is no longer a dog. Of course, this is beta code...but all indications are that it not only performs admirably, but it also exhibits quite acceptable performance under load. That's something that a roughly similar MySQL installation appears to have some problems with, according to the same studies. (Major reference would be SourceForge, but there have been some other reports bandied about. Note that one must take anything resembling a benchmark as an advisory, not gospel. Also note that for every experience or study that favors one product over another, there will undoubtedly be another that says the opposite. So I encourage everyone to take all such reports as ADVISORY ONLY and make up their own mind.) Now, PostgreSQL has triggers and transactions and features that MySQL specifically omits (and indeed eschews) because they say those features are not important and they would slow everything down. Do the stories we're hearing about the new PostgreSQL offer evidence against MySQL's seemingly firm stance against triggers and transactions? I don't know. I suppose time will tell. If anyone is actually following this conversation (other than us die hards), please don't take all of this as MySQL bashing. That's not what I'm trying to do. I use MySQL myself for certain things. As a matter of fact, I find that you can turn even the a Win32(R)(TM)(C)(BC)(AD) machine (which is what I use for my favorite email client, Eudora) into a web development powerhouse with the Win32 versions of Apache, PHP, MySQL, The Gimp and WinCVS. This laptop that I'm typing on right now is outfitted as described. I couldn't buy this laptop without Win98 so I am still using it. (Maybe my next laptop won't be so limited?) Anyway, getting PostgreSQL to work on Win32 is a PITA. PostgreSQL does work on Win32. I know because I got it to work. But I didn't like it, and stopped using it. Doug

I will agree with everything thing you say, with the understanding that there are many projects for which the functionality missing from MySQL isn't necessary. (And with the understanding that there are many projects for which it is necessary.) I have my own personal list of non-standard aspects of the MySQL SQL interface that tick me off, but I still prefer it to the QBE modules in Paradox and Access. And having used versions of Paradox who's support for SQL functionality was very poor, MySQL doesn't strike me as seriously nonconforming. Just the same, more compliance is better than less compliance. The point of SQL is to have a standard way of interfacing with DBMSs. I'm not in a position to do more than speculate, but my impression was that Monty was the sole MySQL developer for many years, and it reflects his idiosyncrasies. Chief among them is a less than full grasp of the concept of atomicity and the SQL standards. That's not an attack on Monty's competence; it just points up the fact that one person can't touch all the bases in an RDBMS project. Now that MySQL is a team effort, it seems to be moving in the direction of better SQL compliance. (Although the whole team seems to share Monty's confusion over transactions.) I'm rooting for PostgreSQL to become the open source app that ate Oracle. MySQL will never be capable of that, but I don't think it needs to be. There will always be a niche for small, quirky apps that have just enough functionality to get the job done and keep the learning curve short and shallow. Bob Hall Know thyself? Absurd direction!

Bubbles bear no introspection.     -Khushhal Khan Khatak