Re: SQL Humor

Joe,

as a long time satisfied reader of your books, I'd like to ask you specifically about this "IDENTITY is bad" thing of yours:

Say I do book-keeping for a club. Say I want to keep track of members, and their addresses, due payments, and other details. Say I can't legally ask them for their SSNs, and anyway would rather not. Now, "Joe Celko, 21 Cedar Drive, 12345 Smallville" may be all I have to identify a given person by. This is a pretty good candidate key (although it is not really guaranteed to be unique), but it is not something that is certain to be permanent. Worse, if I want to use it as a foreign key in a lot of tables, that means I'll be using a multi-column key all over the place, wasting storage space, and complicating any code that accesses the data.

In this situation, I'd be sorely tempted to say "OK, our club will have a 'member number' that identifies each member, and I'll use that as my primary key for the members table, and Joe Celko can just have a coronary if he wants to". :-) (He can also move, or change his name, and it won't be a problem.)

Of course, the member number has no physical reality, and it will be an automatically assigned serial number (without reuse of defunct numbers when people quit or die) -- generally, it seems to be what you rant against.

Am I doing something stupid here? If so, why?

-tih

-- 
Don't ascribe to stupidity what can be adequately explained by ignorance.