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.
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).
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
At 09:36 AM 4/8/01 -0500, Bob Hall wrote:
>Doug,
>
>You've posted your usual good sense, combined with one statement I
>strongly disagree with.
>
>>One of
>>these products is a relational database management system. The other is a
>>quasi-SQL-like-front-end-to-systems-of-indexed-files that has never
>>concerned itself with things like standards conformance.
>
>The implication is that MySQL is not an RDBMS. The only attempt I
>know of to define an RDBMS was Codd's, and no DBMS has ever met the
>criteria he published in a paper in the late 80s (1986?). Even though
>Oracle doesn't meet the criteria of the best known definition (only
>definition?) of an RDBMS, we all seem to agree that Oracle is an
>RDBMS. An RDBMS is a DBMS designed to manage a relational database,
>and a database is relational because it stores data in linked,
>normalized tables. In general, the term RDBMS is used to mean a DBMS
>that can be used to create, modify, and extract data from normalized
>tables. This covers the functionality described in Codd's early
>papers and doesn't exclude all existing DBMSs.
>
>No RDBMS provides a dialect of SQL that conforms perfectly to the
>standard. The MySQL interface uses a dialect that conforms in the
>most important areas. The conformance is close enough that someone
>like me, who refuses to learn non-SQL interfaces because they can
>only be used with the DBMS they were designed for, is perfectly
>comfortable with the MySQL interface. Given the different versions of
>the SQL standard, and the variety of non-standard implementations, it
>seems pretty arbitrary to call one vendor's SQL dialect 'SQL' and
>another's 'quasi-SQL'. And whether the DBMS implements its databases
>as systems of indexed files, or through some other system, looks
>pretty irrelevant from my porch.
>
>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]
