In this post I will show one of the methods I usually choose to generate unique random code.
First, the function that will return the string code....
For further actions, you may consider blocking this person and/or reporting abuse
I would HIGHLY recommend against using str_shuffle for this purpose. It is not a cryptographically random function. Values over time will not be as unique as you may wish them to be. You'll have collisions in real-world scenarios as things scale up.
Something like random_bytes is more suited to this.
Thanks for this comment. As I pointed out in the post this piece of code is not that efficient in large scale application and, you are right, also not for cases where you need a "secure" code, so I agree with you. This is suitable for small application and in the case you need/want to choose which characters your code will be made of.
Anyway, having said that, the uniqueness is granted by the second part of code I posted, so I don't think this can be an issue in any way, no matter how big the things are scaled up. Or am I missing something?
There are no locks on the database, so it has a potential race condition there. Additionally, if this were a multi-primary database (like Galera), those locks cannot be guaranteed anyways. Its usually better to just let existing dedicated unique ID systems to their things, like auto-increment primary keys. They have a lot of consideration in their implementation to ensure uniqueness, down to how they handle thread locking and mutexes.
I don't think it's a matter of locks, nor "unique ID systems" here.
Checking the DB for duplicates can be a a way to ensure uniqueness basing on type of DB and type of application.
But I appreciate your point.
Thanks.
The locks have to deal with the race condition you've introduced in the example code. What happens when there are two active connections to the database at the same time? For example, two separate web requests coming in at the same time. If they both generate the same "unique" ID at the same time, they'll both check to see if the ID exist, which it doesn't yet for either. Then the first goes to insert, and then the second goes to insert. The database lock would be a single mutex to prevent this very condition from happening. Also, standard unit testing usually doesn't test for these types of scenarios either, since they're generally single-instanced, single-threaded. Its just something I want readers to be aware of when building systems like this, and potential issues that'll arise over time.
Your point sure have to be clear. I agree.
No a bad idea at all. Could be useful when you don't have to stick to a fixed lentgh for other reasons.
Can't think about downsides about your suggestion offhand.
Maybe it will work faster than with fixed lenght at the beginning, with few records, but slower at certain point?
Great! Thank you, very interesting! :)