Basically, it's just a phony issue foisted by db semi-literates, usually
product-oriented to the extreme, like the kind who get into arguments
about whether table names should have an 's' at the end or who grew up
with 1980's 4GL's and their puerile successor products that couldn't
support composites. A table/relation/relvar should have exactly the
attributes and exactly the keys that the app needs. It is just
self-flagellation to ignore a dbms feature that will generate some of
them (assuming the dbms doesn't insist on them).
The so-called 'natural' key for all the airwaybills in a ULD on a
typical airline flight segment is about seven or eight attributes. When
the cargo master, at the last minute, offloads a container or two onto
the tarmac, you don't want a ponderous logic to un-assign it and put it
on the plane at the next gate. You need a form of indirection, for that
matter the same is needed in any robotic application such as a freight
warehouse.
Somebody in this thread suggested, if I took the meaning right, that a
design could actually profit from using a single attribute to stand in
for a composite key, where both are part of the design. I've seen such
systems and considered that to be perfectly reasonable, although one of
the big names in the field told me I was confusing physical with
logical. But I say the big names aren't right all the time. I think
there is such a thing as logical efficiency, not just physical
efficiency and sometimes it is a requirement that a 'time-critical'
massive update be coded as simply as possible, leaving the slow-poke
work-a-day requirements to handle the ponderous side. I admit that
doesn't happen very often now with all the fast machinery around. The
decision for me would be based entirely on whether the application
required it, and nothing to do with any dogma.
