Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^5: (OT) Why SQL Sucks (with a little Perl to fix it)

by Theory (Beadle)
on Dec 12, 2005 at 00:16 UTC ( #515921=note: print w/replies, xml ) Need Help??

in reply to Re^4: (OT) Why SQL Sucks (with a little Perl to fix it)
in thread (OT) Why SQL Sucks (with a little Perl to fix it)

I'll agree to stand corrected if and only if I can also require that there is a unique constraint across all columns.

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:

I'm asking for those cities, what's the logical reason for preferring a bag instead of a set? Can you show how this will consistently lead to more correct results?

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.


  • Comment on Re^5: (OT) Why SQL Sucks (with a little Perl to fix it)

Replies are listed 'Best First'.
Re^6: (OT) Why SQL Sucks (with a little Perl to fix it)
by Ovid (Cardinal) on Dec 12, 2005 at 00:34 UTC

    Go back to that post and click the "response to Celada" link I had. I made it clear that the presense of a unique key is not enough. The duplicates are an issue in that case because the table is not in 3NF. If the table is is 3NF, then that unique constraint across all keys holds.


    New address of my CGI Course.

      If the table is is 3NF, then that unique constraint across all keys holds.

      I don't think that's quite true. Consider this simple example:

      CREATE TABLE supplier (
        name TEXT
      INSERT INTO supplier (name) VALUES ('Apple');     -- Computer
      INSERT INTO supplier (name) VALUES ('Microsoft');
      INSERT INTO supplier (name) VALUES ('Apple');     -- Records
      SELECT * FROM supplier;
       id |   name    
        1 | Apple
        2 | Microsoft
        3 | Apple

      This table is in the third normal form, in so far as I understand it, because "none of the non-primary key attributes is a fact about any other non-primary key attribute". However, you'll notice that there is a duplicate, in that "Apple" is listed twice. That's because there are two different companies named "Apple". So this table is technically in 3NF, but you cannot have a unique index across all of its columns.

      That's not to say that this is a good example, or that you couldn't work around this issue in various ways, but it demonstrates, I hope, that 3NF does not mandate that all columns be unique.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://515921]
[Corion]: Veltro: This is due to the fact that one of our webservers doesn't have "our" https certificate but another https certificate. Work is underway (well, on my long, long to-do list) to switch even that server over to "our" certificate
[Veltro]: Corion OK, thanks. At least I understand it now.

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (12)
As of 2018-05-23 11:24 GMT
Find Nodes?
    Voting Booth?