Stored fields ordered left to right

"Jonathan Leffler" wrote in message

 > Dawn M. Wolthuis wrote:

   > >>Dawn M. Wolthuis wrote:


   > >><snip>
   > >>>>> Date writes "...MVS fields are ordered left to right (and
   > >>>>> so MVS files are certainly not relations, and the system is
   > >>>>> certainly not relational)."
   > >>>>>
   > >>
   > >><big snip>
   > >>
   > >>Allow me to play the role of the fool jumping in where angels
   > >>fear to tread.....
   > >>
   > >>Two points which may clarify RDBMS implementation (as opposed to
   > >>theory).
   > >>
   > >>1. The relationships are imposed externally to the data in the
   > >>form of indexes and/or foreign keys. The data itself is
   > >>unordered. [...]
   > >>
   > >>2. Within a table row the physical order of the columns as
   > >>stored on disk need not conform to the logical order of the
   > >>columns as specified in the CREATE TABLE statement. [...]
  > >
  > > 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.

Mathematical relations do not rely on attribute order. The physical
representation of mathematical relations using written symbols on planar
surfaces conventionally uses attribute order for succinctness.

"Bob Badour" wrote in message

<snip>
For anyone who doesn't know, ignore Dawn--she's an idiot. Mathematical
 > relations do not have any particular attribute order. The physical
 > representation of mathematical relations using written symbols on planar
 > surfaces relies on physical order for succinctness.
 >
Your opinions about relations are welcome, but please refrain from telling
me again what an idiot I am as I know your opinion already. If you want
others to join you in thinking I'm an idiot, use logic to indicate the error
of my thinking rather than telling people they ought to ignore me.
Thankfully, I can summon up the self-esteem to continue discussing in this
forum. I wonder how many people you have bullied or offended enough to
leave OR decided this list was not about rational thinking, but rather
personal attacks.

As for mathematical relations, they ARE sets of ORDERED TUPLES, whether on
paper or in concept. The ordering is important for mapping to the domains,
however, it is the case as one person pointed out that with database
relations as laid out by Codd, there is a simple mapping from those
relations to mathematical relations. There is still a vocabulary problem
when working with database models that did not stem from Codd and that DO
have actual mathematical relations in their model. "Relational Database" is
not a useful designation when both DB2 and U2 have this applied to them.
They are based on two very different models.

As someone once said (googling it indicates it was George Box?) "All models
are flawed, but some are useful". The "relational database model" has pros
and cons. The Nelson-Pick model has pros and cons. The XML model (very
similar to the Nelson-Pick model) has pros and cons. One of the advantages
of the relational model is that it has a wealth of documentation spelling it
out as a logical theory. Almost everything written about the Nelson-Pick
model is directed to the implementations (PICK) rather than the abstracted
logical model. I'm attempting to provide more of an abstracted model so
that the pros and cons of the model and not just the implementations can be
discussed. I am guessing that most on this list are big fans of the
relational database model, while I prefer other models. I think that is
what leads Bob to his false conclusion.

--dawn