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
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
