|Do you know where your variables are?|
Re^5: (OT) Why SQL Sucks (with a little Perl to fix it)by Theory (Beadle)
|on Dec 12, 2005 at 00:16 UTC||Need Help??|
I don't think that's what you want. Every row (tuple) has to be distinct from every other row. Having a single primary key column makes that so. The problem comes in when you try to query that table. Given this table:
id | city | country ----+--------+--------- 1 | Paris | France 2 | London | England 3 | Paris | Texas 4 | Paris | France
The presence of the primary key (id) makes it a proper relation. However, when we try to query it like this:
select city, country from test; city | country --------+--------- Paris | France London | England Paris | Texas Paris | France
That is not a relation, because it has a duplicate in it. The problem isn't that the table isn't a relation, but that the result of our SQL query isn't a relation. So what is it? This gets to dragonchild's other point, to which you said:
As I said the result of the above query is not a relation, but a report on the contents of the columns I queried, with the number of rows replicated. It makes sense in that it reports how many rows they are, and SQL is a row-oriented reporting language. So it is consistently more correct if my question is "What are the contents of the city and country colunns in all rows?" Of course, that's not usually a very useful question, but it is at least consistent with how SQL works.
So that's how it makes sense. And as you and I agree, that makes it unrelational. It's a report on rows in a table, not a set created by querying a relation.