>>>>[a bunch of good points.]
>>>>
>>>>There are better ways of creating identifiers.
>>>
>>>
>>>Do these same problems apply to *any* system-supplied
>>>key? It seems that your "The entire, whole, completed
>>>set is presented to Foobar all at once, not a row at a time"
>>>objection would apply to any such.
>>>
>>>But it seems pretty common that I just want to have a key,
>>>and I don't care what the specific values are (as long as
>>>they are unique,) and I'd like to have the system supply
>>>it for me. Is there no clean way to do this?
>>>
>>>
>>>Marshall
>>>
>>>
>>>
>>>
>>
>>In the worst cass scenario, the whole set of columns is your key.
>>If the whole set of columns doesn't form a key, than you surely are
>>making a design mistake.
>>
>>So you'll always have a natural key.
>>
>>Costin
>>
>>

> > > I would tend to agree, except that I must accept the fact that there might> not be enough discriminating attributes to uniquely identify what is> conceptually termed an "entity" or a "relationship". There can be a wide> variety of reasons in the practical world where this might be so. Unless> you think, for example, that everyone should be capable of uniquely> identifying a "person" by recording geo-spatial information and what-not as> Celko has posited in the past?> > Regards,> > Dan Guntermann> >

The idea is that if you don't have enough attributes from the business
domain, you have to come to an agreement with the business people how
you create such an attribute and make it part of their business.

In the case of the Person example identified above, the business people
might agree to a customer number, and have a business rule for
generating such numbers for new customers (it may be and often times is)
a bit more elaborate than an auto-increment.

An "auto-increment" style might suffice, i.e. an integer attribute that
always gets assigned the next available value. Even in the later case
Joe Celko's observation is absolutely pertinent: you better not make
that column auto-increment, because techincally you're asking for
trouble: you'll get in trouble with bulk inserts and import/export for
example. You can easily solve the id generation issue without
auto-increments,

In any case, the idea is that by the time you ended the conceptual
modeling (aka analysis, information modeling, etc), have all the
business rules written down and came down to the nitty gritty details of
database design per se, you better have identifying attributes for all
your entities.