> Steve Dirickson's points about TPC-R instead of D are well
> made, and I both envy and respect his knowledge of these standards.

Thanks for the kind words, but don't get too impressed; the only "knowledge"
I have is where to look up this stuff--in this case, www.tpc.org.

> The TPC-C standards seem
> more readily suited to what I suspect most of us are used to
> seeing and
> supporting in an application. No SQL interface is required,
> IIRC (Steve?).

Right. Part of "0.1 Introduction" reads:
 "Although these specifications express implementation in terms of a
relational data model with conventional locking scheme, the database may be
implemented using any commercially available database management system
(DBMS), database server, file system, or other data repository that provides
a functionally equivalent implementation. The terms "table", "row", and
"column" are used in this document only as examples of logical data
structures."
Also, "Clause 2: TRANSACTION and TERMINAL PROFILES", "2.1 Definition of
Terms", starts out as follows:
"2.1.1 The term select as used in this specification refers to the action of
identifying (e.g., referencing,
pointing to) a row (or rows) in the database without requiring retrieval of
the actual content of the identified row(s).
2.1.2 The term retrieve as used in this specification refers to the action
of accessing (i.e., fetching) the value
of an attribute from the database and passing this value to the application
program."
They're clearly leaving the door open for just about anything that can act
like a database. The constraints are on the transactions, ACID properties,
data contained in the database, etc.