Hop on over to Perlmonks and you can read one of the reasons SQL sucks (it's bag-oriented instead of set-oriented).
Re:Database in Depth
Ovid on 2005-12-11T18:43:32
Yes, tuples can be ordered while a set is not, even though tuples in the relational model are unordered. I believe the distinction here was to ensure that you don't get "Bob, Paris" (assuming "customer, city") and "Paris, Bob" (assuming "city, customer") in the same query and thus getting a result which is effectively duplicated and having negative impacts on subsequent operations. In this sense, what make a "tuple" a "tuple" is not the ordering of the attributes but the names of them. This is actually fairly common in computer science.
Given that, how is a 'database relation' different from a mathematical one?
Re:Database in Depth
fxn on 2005-12-11T18:59:08
Tuples in the body of a relation (in the book's nomenclature) are essentially a set of pairs (attribute, value), where attribute is some pair (type, name) in the header. That's the way the header and the element of the set in each "row" are related, by the attribute coordinate.
The choice of sets reflects the need to avoid the possibility to refer to columns by index, in opinion of a friend of mine.
In math a relation is something much more simple. Given a cartesian product S = S1, S2,..., Sn, a relation is a subset of S.
For instance, the relation "less than" in ZxZ is the set of pairs where the first coordinate is less than the second: (1, 2), (5, 100), etc.
In particular, the elements of a relation are tuples, ordered collections of elements of S1, S2,..., Sn.
In my view the idea behind the formalism in Database in Depth is that a relation is something with some plumbing structure to relax the cartesian product to a set of sets, and to be closer to the normal usage (hence the introduction of names, and the separation header body). But as you see that is not a mathematical relation.