But it is *not* a special case. In reductio ad absurdum, what you're suggesting is that no results set could ever contain duplicate fields. So,

• Your company personnel database could not be allowed to have two people with the same name, because if it did, and you asked for a print out of all the names, it would violate your rule.
• And you couldn't employ two people with the same age, or date of birth.
• Hmmm. What about number of legs or eyes or ears?

Now I'm getting absurd, but that is what I set out to do.

I guess your response will be: "It doesn't make any sense to produce any of those results sets. What is the point of a list of names with duplicates, if you cannot distinguish between the duplicates". That presupposes that there is no legitimate use for such a list of names, but you cannot know that.

Name tags for the company beano, or name plates for office doors, lockers or mailslots.

It doesn't matter that the two John Smiths have identical badges/labels. Those that know them will know the difference, and those that don't, won't care. They'll just say "Hi John, what do you do"? Anyone who needs to know the difference will. Including them.

Another example. You are shipping boxes of product X to customers. Your business rules, encapsulated within your database, know how many X will fit inside each type of box, how much those will weigh, and how much they will cost to ship. That's all worked out and stored inside your DB. Now you need to produce a set of shipping labels to stick on those boxes. Where a customer has ordered more items than fit in your largest box, or a number that better fit into 2 smaller boxes, the query will produce an identical label for each box going to that customer.

It doesn't matter which label goes on which box, (nor which individual Xs go in which box), there is simply no good reason to distinguish them.

It does matter that both (all) boxes get labelled, and for the DB to quietly fail to produce the duplicates for some high falutin' principle or mathematical reasoning is bogus. Yes, it would be possible to add a distinguishing box number to the DB to make them distinct--but it's equally possible to use the DISTINCT keyword whenever that's what you need.

And that latter course does not require you to add artificial fields to your DB tables just to satisfy some principle.

This is very similar to that other hoary ol' chestnut of the to be, or not to be relational debate.

Storing hierarchical data in a relational database is a pain. Yes, the relational gurus will tell you that it is perfectly feasible to do so, and there is an example (by tilly?) somewhere around this site. But it requires a mitt-full of non-data "auxiliary fields", and one (or more) artificial auxiliary tables per level of hierarchy, to achieve the structuring; the real data has to be duplicated in several places to achieve it; you have to preprocess your data before insertion in order to invent the auxiliary field values; and every 'simple' query of that data the depends upon the it's structure for the correct selection becomes a multi level affair requiring a general purpose program to piece the hierarchy back together. It is, in every way a PITA to do. There are very, very few people that can sit down and remember how to do it without looking it up.

This is wrong. The world, and especially the commercial world is full of hierarchical data. Having to pre- and post process that data and add all manner of extra, DB-only numbers to it in order to get it in and out of your DB, simply so that your DB can pretend the world and everything in it can be represented as a 2D grid of tuples and relations is daft!.

Does that mean that relational DB are useless, and we should return to the bad old days of hierarchical DBs? No, obviously not.

What is does mean, is that whenever you try to impose one, mathematically pure view onto everything in the world, you create as many problems as you fix. What's wrong with having two datamodels--a relational one and a hierarchical one--that coexist and interoperate?

Many data, and many uses of data, elegantly and efficiently fit the relational view. Many data and uses do not. There are so many examples of hierarchical data in the real world, bending them all to comply with a mathematical principle is ....