Hi all. I'm sure I can't be the first person to ask this question but a search of the net leaves me confused.
I need a unique identifier in an SQL table and for complicated reasons I don't want to use auto-increment. So I thought I would use a pseudo-random method instead. I am NOT scared of people guessing the unique identifier, it just has to be unique in order for the database to work properly. So I looked at the uniqid() function and see it is based on the "current time in microseconds" and when I test it out I see that it increments (very quickly) when run repeatedly. If it is based on JUST the time, then it should repeat every 24 hours, thus making "collisions" possible, which I don't want. If it is based on the time AND day, then that's fine....I can use it. So here's the problem.... When I calculate the number of microseconds since 1970 I get a 16 digit number. But uniqid() only gives a 13 digit number. Calculating the number of microseconds in a day gives 11 digits. So it seems to me that the numbering sequence will repeat every 100 days, which risks collisions also. Can someone explain how uniqid() is really calculated, so I can make a proper judgement about how to use it? Please don't suggest using a hash of a number generated by uniqid(). Hashing a small number into a longer one does not add entropy, it just transforms the input number, so it does NOT alter the risk of collisions so there is no net advantage. I had a thought to just append the current date to the uniqid() result but I'm interested to know if anyone has a more elegant solution. Thanks in advance. Angus
