Reputation: 221
I have an idea. It might be bad, for reasons not known by me, but I would really appreciate your feedback on this!
We've been using Session ID's in a PHP project. And for the first time in 4 years, a duplicate sessionid was generated. Luckily enough I randomly decided to go looking through the Customers Table because I was bored and noticed there was a duplicate entry in the sessionid column and changed it, and references to it, before any real problems occured.
Which led (or lead?) me to ask myself this question:
Basically, any type of ID, be it a session id, uuid or guid can eventually be duplicated because the length of them is not infinite. So then I got thinking, because we never want this to happen again.
I thought, What if we use a combination of date and time, as an identifier? This wouldn't be "random", but it would solve the duplication issue. For example:
14th of May 2011 04:36:05PM
If used as an identifier, could be changed to:
14052011163605
The reason this form of ID will never become duplicated is because no date, combined with time in the future will ever be the same as one in the past, or present.
And since, in our case, these ID's are not meant to be seen by anybody, there's no reason for it to be random, is there?
I'd love to hear your thoughts on this, and, how you approach situations like this. What's your best method of generating [practically] unique ID'S?
Upvotes: 3
Views: 5695
Reputation: 3671
UUIDs are already generated based on nanosecond intervals of time (see this wikipeida article). If you are using PHP, I'd suggest this page to take a look at how to generate the different versions, depending on your use:
http://php.net/manual/en/function.uniqid.php
The reason you can't guarantee uniqueness is that you have to eventually pick a size limit for the actual string/variable containing your UUID, so there is always the potential for a duplicate. Given the number of possibilities for a UUID, though, this should be practically impossible.
I agree with the other posters... this probably shouldn't ever happen. How are you actually generating unique IDs? Are you sure your code is properly creating them?
Upvotes: 2
Reputation: 54242
Why not just make your session ID column a unique column, and then generate a new session ID if you get a constraint violation error? That way the database will find this problem for you in basically the same way that you did (and as a bonus, it can fix it too).
Upvotes: 2
Reputation: 180004
The reason this form of ID will never become duplicated is because no date, combined with time in the future will ever be the same as one in the past, or present.
If you only had one user, this would be true.
Upvotes: 4
Reputation: 7505
UUID / GUIDs are very large (larger than the count of particles in visible universe)
your date/time solution will fail on high loads. what happens when i need 100+ new ids per second ?
Upvotes: 3