Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Teach SELECT DISTINCT first!

Re: Teach SELECT DISTINCT first!

From: Laconic2 <laconic2_at_comcast.net>
Date: Tue, 27 Apr 2004 10:44:13 -0400
Message-ID: <ttadne9jwZQY7BPdRVn-tw@comcast.com>


Sorry, but it isn't just a sophism, although it looks like one, on the surface.

The fact is that representing relations (or, for that matter sets) inside a computer is a much bigger challenge than most people think. The reason is that the bits in memory have a natural order, according to the addressing scheme of whatever memory they are in. Representing a set, without implying order, necessarily implies imposing an artificial order on the representation, that is not homomorphic to the thing being represented.

That is why I asked, a while ago whether a pizza with pepperoni and onion is the same thing as a pizza with onion and pepperoni. If the list of toppings truly represents a set, then, in order to let a PICK record represent a relation,
we have to forbid duplicates, even when the MV fields contain the same values, but in a different order.

But if the list of toppings represent a list (NOT a set), then two lists made up of the same values, but in different orders, are different lists, and therefore don't duplicate each other.

Telling whether two sets are equivalent, without doing any sorting, is nearly impossible. That is why, IMO, Codd imposed the "no compound columns" rule on 1NF, even though the rules of relational algebra don't require that.

And it's the "no compound columns" rule, not the "no duplicate rows" rule that provoked the long discussion of whether 1NF was a good idea or a bad idea. Or a good idea in 1970, but a bad idea in 2004. And that's not sophism. Received on Tue Apr 27 2004 - 09:44:13 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US