>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

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]

Reply via email to