>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]
