Hi,

It's commonly understood that in the relational model:

1. Every relational operation should yield a relation.
2. Relations, being sets, cannot contain duplicate rows.

Imagine a 'USERS' relation that contains the following data.

ID FIRST_NAME LAST_NAME
1 Mark Stone
2 Jane Stone
3 Michael Stone

If someone runs the query "select LAST_NAME from USERS", a typical
database will return:

LAST_NAME
Stone
Stone
Stone

Since this is not a relation - because it contains duplicate rows -
what should an ideal RDBMS return?

Regards.

On 8 oct, 15:44, Seun Osewa <seun.os... (AT) gmail (DOT) com> wrote:
is obvious.

Suppose that appart from you, there are two members of your family,
bearing the same name than you working in your company. Suppose you
ask your best friend, that talks to you on a daily basis, visiting
*Give me the LAST NAMES of ALL EMPLOYEES of my company* ? What will
you think if that friend repeats three time the same thing.

Cimode wrote:

Ironically, the query is in plain english. So plain, in fact, it sounds
a lot like an exam question.

Then again, the source IP does trace back to Nigeria. Nigerian scammer
looking to upgrade his skills, maybe?

On 8 okt, 21:36, Cimode <cim... (AT) hotmail (DOT) com> wrote:
Allthough your intent is obviously right, it might be helpful to
actually spell out the answer, instead of answering the question with
a counterquestion ... Even if that counterquestion seems more than
rhetorical enough _TO YOU_.

The OP asked the very same question on another forum too. I suppose
he is trying to get "second opinion" or some such.

On 9 oct, 13:19, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
driving it. Getting an unintuitive point across to somebody who
probably never read any significant RM theory material requires
different language and lexicology than the formal one.

At best, it triggers further interest on the subject, at worst, it
scares database practitioner wannabes who don't want to put some
effort onto understanding things. The OP seems to belong to the
former (I hope).

On 10 okt, 00:14, Cimode <cim... (AT) hotmail (DOT) com> wrote:
Hmmmmmmmm. Now I'm just being curious.

How can you match this claim of yours with the fact that the OP
explicitly states in his question that

"Since this is not a relation - because it contains duplicate rows -
".

Do you think there exists any source _BUT_ "significant RM theory
material" where he could have acquired the knowledge to state that ?

I'm also curious as to why he's asking to be pointed out what I think
should be obvious, but then again recent discussions on other subjects
have revealed to me that there is no predicting when people will fail
to see the obvious, merely because of certain kinds of mental block
they happen to be suffering from. I'm granting the OP the benefit of
the doubt that he might be suffering from a mental block of the kind
"surely if SQL is so widespread, then everything it does must be
right".

Erwin wrote:

You assume the text requires knowledge instead of copy/paste. I suspect
he got the text from a test question.

On Sun, 10 Oct 2010 08:36:38 +1000, Erwin <e.smout (AT) myonline (DOT) be> wrote:

In the context of recent discussion on the ttm mailing list regarding
ORDER BY, it's not clear to me that correct answer is indeed obvious. (In
fact, given my track record on cdt, I'm not sure that I am thinking of the
correct answer).

With that caveat in mind, given that, with the OP's database, the query

SELECT FIRST_NAME from USERS order by FIRST_NAME

presents the user with something that is not a relation, it seems strange
to require that

SELECT LAST_NAME from USERS

should. (Apart from that projection is a relational operator, and order by
isn't, but that seems to me at least to be slightly subtle).

Cheers,
Joe

On Oct 9, 10:56*pm, "Joe Thurbon" <use... (AT) thurbon (DOT) com> wrote:
SELECT is not the same thing as projection, even if the columns in the
select list are a proper subset of the columns in the table. It
follows that SELECT does not necessarily return a relation, even
without an ORDER BY. SELECT DISTINCT is analogous to taking a
projection over the select list.

On Sun, 10 Oct 2010 13:23:50 +1000, Brian <brian (AT) selzer-software (DOT) com>
wrote:

Indeed. Thanks.

Please revise my parenthetical to read:

(Apart from that SELECT has, in projection, a relational operator that is
a close analogue, and ORDER BY doesn't, but ...)

Of course, my above post presupposes that Erwin's and Cimode's 'obvious
answer' to the OP's question is that SELECT should behave in the same way
as SELECT DISTINCT. (Is that what you'd choose, too?)

Cheers,
Joe