RE: Can sets have order?

Michael Kay writes:
 > > In fact, in databases, relations are *multisets*, allowing for
 > > duplicates.   I.e., tuples with the same values but different
 > > internal row-ids are allowed.
 > 
 > In Codd's relational model, relations are sets.
 > 
 > In SQL, relations are multisets, because a relation can contain two tuples
 > that are indistiguishable.

You're right. Sorry.

 > In every real RDBMS that I know of, relations are sets, because two tuples
 > in the same relation are always distinguishable by some kind of id, which
 > means that the relation no longer contains duplicates.

If a table is specified without primary key, it may contain tuples
which coincide in all their attributes. The only possibility is to
distinguish them by their "rowid" pseudo-attribute which does not
belong to the data (e.g., used for eliminating duplicates). They may
be exchanged without changing the application semantics of the
database.

So the point is, how one interpretes "duplicate". Value-Equality
(or Deep-Equality in nested or object-oriented models), or equality
wrt. an artificial internal id.

 > > For XPath/XSL I would say that it is somewhere between sets and
 > > multisets since a result set can contain the same values several times
 > 
 > Unlike the pure relational model, but like most relational implementations,
 > nodes in XPath/XSLT have identity, so a node-set cannot contain "the same
 > node" twice. It can contain two nodes that are equal, but not two that are
 > identical.

Not the same node, yes, but nodes which have the same values for all
their attributes and attributes of subelements (i.e., which are
deep-equal).  Such nodes may be exchanged in the node set without
changing the behavior of any XPath query.

If such a result set is sent to another application, it is not
possible to say "this node _is_ the node xy from the original
document" - it is only deep-equal to some of them.

Wolfgang

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list