Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Stored fields ordered left to right
Dawn M. Wolthuis wrote:
> "Jerry Gitomer" <jgitomer_at_erols.com> wrote:
> > Yes, this is most helpful. This is PRECISELY my understanding -- > that deciding to remove the ordering from relational tuples is an > implementation issue and not about the logical theory of relations. > > I work with relations that are mathematical relations and are > therefore ordered tuples. The model behind XML documents is also > one of ordered tuples. So, if you hear of folks who might sometimes > spout that their database model is "more relational" than RDBMS's > it sometimes is due to this particular issue. > > Based on this, it sounds like a response to Date that says that > mathematical relations are ORDERED and not unordered tuples so that > this particular point is irrelevant (and, in fact, wrong) would be > an accurate response, right?
It depends on the premises from which you work.
One of the documented differences between mathematical relations and relations used in database theory is precisely this one - that the elements in a tuple of a mathematical relation are ordered (usually ordered pairs, in fact) but database theory uses unordered tuples, where each element logically consists of the combination attribute name, attribute type and attribute value. Of course, in a system without inheritance to complicate matters, the attribute type associated with a given attribute name is the same for all tuples in the relation (but the converse is not true). The difference between ordered mathematical relations and the unordered database equivalent is clearly stated in Codd's original (1970) paper, incidentally:
Accordingly, we propose that users deal, not with relations that are domain-ordered, but with relationships which are their domain-unordered counterparts.
[Note the implied distinction between what users see and what the system manages, too.]
Many practical systems store each record (physical analogue of a tuple) with the fields (the physical analogue of an attribute) stored in the same order, which makes it easier to locate a given field within a given record. And many systems make life still easier by storing the data for a given field in a constant width, so it is trivially possible to pre-calculate the offset into the record for a given attribute value.
To get back to the question - if you change the premises on which your version of relational theory is based to state that your tuples are indeed ordered, then of course Date's statements no longer apply. The theory about which he is making statements states that tuples are unordered. Both are valid sets of premises, but they are different sets of premises, and statements made about one are not valid for the other.
As to which set of premises is better - that is a separate discussion. I strongly suspect there are a rather large number of issues that have to be resolved when you use ordered tuples rather than unordered tuples. Most notably, A JOIN B is not the same a B JOIN A under the ordered scheme - with consequences that need to be considered very carefully.
And, reverting to the final question again - no, Date's comments are neither irrelevant nor wrong in the system about which the comments were made.
-- Jonathan Leffler #include <disclaimer.h> Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/Received on Sat Dec 27 2003 - 21:26:05 CST