>>I think of a customer entered key, much as I would a first name. Good information, but not something you can rely on. Useful for searches, but not a guarentee to find what you are looking for. I use GUIDs for my pk's. Love them.
>
>GUIDs of course solve the problem of creating PKs for computers which are not always connected. I was thinking about the following alternative, but never actually tried it: assign each branch office a different number, and create PKs like:
bintoc(branchnum, 2) + bintoc(SerialNumber("TableName"))>
>... where SerialNumber() gets a sequential number from a special table.
>
>This would use 6 bytes, instead of the 16 used by the GUID. Any opinions?
Yeah - disk space is cheap - us guids. They scale well and make if very nice when you want to merge a lot of data together that the client SWORE would never have to be merged together. And there is no chance the "special table" is going to get out of whack because of a bad backup restore, system crash or weird user behavior.
I've even gone to using 36 char bin guids just so they'll play well with SQLServer if I need to move the data up.
Charles Hankey
Though a good deal is too strange to be believed, nothing is too strange to have happened.
- Thomas Hardy
Half the harm that is done in this world is due to people who want to feel important. They don't mean to do harm-- but the harm does not interest them. Or they do not see it, or they justify it because they are absorbed in the endless struggle to think well of themselves.
-- T. S. Eliot
Democracy is two wolves and a sheep voting on what to have for lunch.
Liberty is a well-armed sheep contesting the vote.
- Ben Franklin
Pardon him, Theodotus. He is a barbarian, and thinks that the customs of his tribe and island are the laws of nature.
