Re: Re: PostgreSQL versus MySQL

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