Suppose I am generating a unique code base timestamp for example I am generating the uniqe code base date('d-m-YHis') output = 25092020052212 now this is 14 digit code I wish to make this 8 digit.
How I make this code shorter but unique … can be bycrypt like this bycrypt(25092020052212) in 8 digit
I am very sorry I am new in PHP and might above I unable to do bycrypt function but as above I try to give my idea. If develper you know please help me.
What if I told you that this output can be represented as: 1601011332 1011111011011010111111010000100 5F6D7E84 (hey look, thats 8 characters…) vtr9CA==
TLDR: An 8 character translation of what you’re looking for is the hexidecimal value of the current timestamp up until February 7, 2106.
Note: This is NOT a unique value if your webserver performs this operation more than once per second.
You can try this if you don’t generate code on demand, but have a database of ready-made and unique ones. Not safe of course, but fast))
And when you need to submit code, you simply select a line, display its code, and then delete it. And such a list should be gradually “replenished” with new entries as needed.
This is not really on the topic of the thread, but the concept of pre-generating unique shorter codes/ids is not a bad one.
It all depends on the use case, if you require an id to stay unique for a set time period for tracking etc, and you go through millions of these ids a week, it is almost a requirement.
The reason for this is that the longer after you started using them, the more duplicates will be generated by the code, making each “on the fly” generation take more and more time. While if you pre-generate them, it takes a few ms to take one.
Huh? What part of unique do you not understand? If an ID is unique, it is unique forever otherwise it is no longer unique.
If you have a problem with “more duplicates” your ID generation is flawed. Facebook, Flickr and Twitter generates billions and billions of unique id’s. They do not “pre-generate” any of them nor do they suffer from any duplication problems.
On the fly, Twitter generates AT MINIMUM 10,000 unique id’s PER SECOND, PER PROCESS across a distributed network of thousands of servers with a response rate of less than 2 milliseconds and are partly based on time. How in the world would you be able to pre-generate id’s that have any basis on time if that time does not exist yet? At the rate Twitter uses id’s you would have to generate, store and then retrieve them as fast as they get used. The overhead and bottleneck would be tremendous.
So like I said, pre-generating id’s is a terrible idea and is not scalable at all.
That is not correct in many industries, if a reference only needs to be unique for X period of time, it is not uncommon to reuse old ids again. This makes it possible to use shorter ids, which can be preferred depending on the use case.
It might be an idea to read the full post first? I explicitly mentioned shorter ids, which depending on the use case, can be preferred to longer ids.
In some cases, you also do not want the id to be predictable, which is normally the case when you generate them on the fly based on a set structure/architecture.
The longer the id can be, the easier it is to generate unique numbers on the fly. A long id is normally not an issue for “web/app” use, other than it increases the bandwidth required. But for systems that operate against offline components or even old legacy systems, there might be specific requirements for the size of the id.