On Sun, 8 Apr 2001, 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.
The only thing I question in this is that without transaction support,
what exactly is MySQL "managing"?
The data in the normalized tables.
MySQL is providing an SQL frontend to a
bunch of tables and indices, that is it ... it is up to the programmer to
handle the "managing of data" part where it revolves around being
relational ...
I've developed database apps in which the data was inserted in batches, which meant that transactions were unnecessary. On the other hand, the apps needed an RDBMS to handle normalized tables.
Also, note, that even today, MySQL does not handle transactions, Berkeley
DB does, and its purely optional, and per table. So, effectively, it has
"transactional tables", its not a "transactional system" ... if you didn't
define a table for transactions when you created it, you just created your
weak link ... again, its not MySQL that manages the system, its the
programmer who has to do it ... *shrug*
Transactions have to do with the environment the DBMS operates in, not the type of database. Relational database theory was developed when multi-user OSs were still pretty new, and database processing was batch processing. In that type of environment, ACIDity isn't an issue. In an OLTP environment, even OODBMSs have to deal with transactions. At the same time, the lack of transaction support doesn't disqualify an OODBMS from being object oriented. Futhermore, some datawarehousing and web projects involve relational databases that are inserted and updated in batches at night, making transactions unnecessary.
I'm not trying to claim that MySQL can handle all types of db applications. MySQL is a niche product that was never designed to handle certain types of applications. My point is that whether a DBMS is relational depends on the structure of the data it deals with. Whether it needs to support transaction depends on the environment it operates in. I think that your point is that in an OLTP environment, lack of transaction support screws up the data to the point that the database becomes useless. I agree, but not all RDBMSs operate in an OLTP environment.
Bob Hall
Know thyself? Absurd direction!
Bubbles bear no introspection. -Khushhal Khan Khatak