Lists Home |
Date Index |
- From: "W. E. Perry" <firstname.lastname@example.org>
- To: email@example.com
- Date: Sat, 06 Mar 1999 10:09:37 -0500
David Megginson wrote:
> A DBMS is something that manages data *and* passes the ACID test
> (Atomicity, Consistency, Isolation and Durability). This isn't a
> question of "I want feature X" -- the ACID test is what distinguishes
> a DBMS from, say, the Unix file system (which can also manage data).
I am going to be the old fogey here, with experience of databases going back to IMS and R:
ACID is (one possible) test of a transaction processor, not of a database. It was precisely
the misguided emphasis upon ACID qualities which bloated the relational model into the
transaction-oriented behemoths sold today. For at least ten years we have tried to undo that
direction by re-imagining the original relational concept as the data warehouse and, when that
too became too bloated, the data mart. There is an opportunity with a true XML database to
describe, and implement, transactions without surrendering to the siren song of two-phase
commit. The key is understanding that there is no obvious or natural boundary to a
transaction. Because of the inherent differences in the perspective of every participant to a
transaction, each or them will describe a different set of elements to the transaction and
different specific relationships among them. In the data world there is no omniscience which
sees the transaction whole: to imagine it as a single, identifiably boundable unit is to
deprecate the central task of each participant--to construct a transaction which is
understandable to and processable by his own system. That is an ongoing implementational task,
not just a conceptual one. In the real world it resolves to this: how do I get what I have to
become what you need? What I have and what you need are both structures, and the two of them
will incorporate some set of similar or analogous elements, which gives them the common terms
on which they can define and communicate the transaction which they are attempting to execute.
The definition and the maintenance of each of these structures is the role of the database.
Yet each of those structures is peculiarly unique, and both are ephemeral in the specific
terms of the transaction which they facilitate. Yes, the transaction, once executed, endures.
But the terms in which that durability is communicated--indeed the very substance as which it
is preserved--may be utterly different in the systems (and, I would hope, in the databases) of
each of the participants. Precisely what each of those systems, or databases, does not exhibit
are the ACID qualities through which some would hope to define the identity, uniqueness and
permanence of that transaction.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)