Re: An improved technique for database primary keys

in reply to An alternate technique for database primary keys

The choice of “8 characters’ is arbitrary, but it should simply be long enough that a “collision” is impossible.

I woke up screaming when I read that. And I wasn't even asleep.

Comment on Re: An improved technique for database primary keys

Replies are listed 'Best First'.
Re^2: An improved technique for database primary keys by sundialsvc4 (Abbot) on Nov 05, 2010 at 13:24 UTC
Sleep well. It is a calculated-risk, and of course the index in question must be `UNIQUE` so that colliding values, if they were somehow generated, would not be stored. You could, of course, go so far as to use Microsoft’s UUIDs (GUIDs). The notion is simply that, if the string is random and sufficiently long, key collisions in-practice “ain’t never actually gonna happen.” Your mileage may vary. Choose appropriately. If, in whatever context you may be dealing with, this admonition isn’t sound, then don’t follow it. Peace.

Replies are listed 'Best First'.

Re^2: An improved technique for database primary keys
by sundialsvc4 (Abbot) on Nov 05, 2010 at 13:24 UTC

Sleep well. It is a calculated-risk, and of course the index in question must be UNIQUE so that colliding values, if they were somehow generated, would not be stored. You could, of course, go so far as to use Microsoft’s UUIDs (GUIDs).

The notion is simply that, if the string is random and sufficiently long, key collisions in-practice “ain’t never actually gonna happen.” Your mileage may vary. Choose appropriately. If, in whatever context you may be dealing with, this admonition isn’t sound, then don’t follow it. Peace.

In Section Meditations