We have referred often to a novel technology—the TransRelational™ Model (TRM)—that offers the opportunity
to implement true RDBMSs (TRDBMS) that perform significantly better than
traditional SQL implementations; what is more, we argued in PRACTICAL DATABASE FOUNDATIONS paper
#8, The Final NULL
in the Coffin, that TRM lends itself particularly well to the logically
correct solution to missing data. Unfortunately, we are not yet at liberty to
disclose further details beyond Appendix A in Date’s AN INTRODUCTION TO DATABASE
SYSTEMS, 8thed. (pp 941-66), and
his brief seminar on
the subject.
Recently, however, I received comments from a reader who,
based on some calculations, suggested that the technology would fail to fulfill
its promised superior performance. We advised him to withhold judgment until
sufficient information about TRM is published, but he decided to post his
comments publicly to invite reactions by others. He then reported that his
posting, The
TransRelational Model Performance Concerns in the comp.databases.theory
newsgroup, draws the conclusion that the TRM can only be considered for main
memory databases.
Steve Tarin, the inventor of TRM, thinks that this conclusion
is just plain wrong, and should not go unanswered. Despite a heavy schedule,
Steve will try to post a short reply soon himself. He has also requested a
colleague familiar with the technology to formulate a response, to be posted
very soon.
In the meantime, we would like to point out that, first, even
though TRM is at a lower level than the relational model (RM), it is
nevertheless a model, and not a physical implementation. Therefore, it
can be implemented in any of number of physical ways, each of which will
exhibit different performance characteristics.
Second, C. J. Date, who has studied the technology in detail,
draws attention to the beginning and end of the Appendix A mentioned
above (emphasis added):
In this appendix, we take a brief look at the way TRM works.
Naturally, we do not have room to cover everything; to keep our discussion
within bounds, therefore, we have decided to ignore (a) updates and (b)
secondary storage; in other words, we adopt the fiction that the database is
(a) read-only and (b) in main memory. Please do not conclude that TRM is
good for read-only, main-memory databases only, however—it is not. For a
detailed description of all aspects of TRM, including update operations and
databases stored on disk, see the [forthcoming] tutorial book by the present
author [GO FASTER! THE TRANSRELATIONAL™ APPROACH TO DBMS IMPLEMENTATION].
…
We have discussed what the TR model looks like for
read-only, main-memory databases. Although our discussion has unfortunately had
to be quite superficial, we hope it was sufficient to give a sense of how TRM differs significantly from
conventional, direct-image technology. At the same time, many questions will
doubtless have occurred to you. For example:
·
Can the Field Values and Record Reconstruction Tables
be maintained efficiently in the face of arbitrary updates to the database?
·
Since the Record Reconstruction Table is isomorphic to
the original file—in effect, to the original relation—but has a pointer in
every cell instead of a data value, might not TRM require much more storage than
conventional, direct-image implementation?
·
In a disk-based system, will not the zigzagging mean a
lot of random access and terrible performance? And can binary search be made to
work efficiently on the disk?
And so on. Such questions are indeed serious ones, but
(sadly) this is not the place to address them; suffice it to say that they
can and have been addressed satisfactorily, and the solutions have been
implemented. For more information, see [above forthcoming reference].
Otherwise put, it is the assumption that TRM uses the same algorithms on disk
that it uses in memory—the latter is what the appendix describes—that has led
the author and readers of the thread to question performance. Since,
calculations notwithstanding, that assumption is incorrect, the conclusion is
not warranted.
Posted 12/03/04
