Background:
I am creating a service booking website. Each order needs to have a unique order number. I have chosen 16 digits because that's what the previous software used.
Questions
I am not sure if there is any benefit to putting data into the order number or if it should just be a purely random string.
If it is just a random string then its only purpose is to act as an ID. If that is the case, then why not just use an incremental ID? Other then to obfuscate the number of orders we have generated to the end user I can't think of a good reason.
If it is a good idea to put data into the string, what kind of data should I include? Probably the date of the order, but other then that I don't know.
I am currently generating a purely random 16 digit string like this.
public function generateOrderNumber()
{
$time = time(); // Time (CET) to hash
$token = md5($time); // Hash stored in variable
return str_shuffle(substr($token, 0, 16)); // Hash shortened to 5 chars and randomised
}
However I am not sure if this is good enough for production.
If you need globally unique, say across multiple databases that are synchronized at intervals, then I'd go with standard 128-bit GUID which could be squeezed into 16 8-bit bytes to maintain backwards compatibility. PHP has com_create_guid to generate GUIDs.
MD5 only produces values in the a-f0-9 range which is severely limiting here. You really need to expand this and use the entire alphabet, maybe even Base62, a variant of Base64 minus the two "annoying" characters.
A cryptographically random number, not the junk rand() produces, encoded as a 5-character Base62 value could work.
If you need people to be able to read and write these values by hand you'll want to omit 0, O and 1 and l and I for clarity.
Remember, on really short values you will probably get collisions so you'll need to test any INSERT you do against a UNIQUE constraint and retry if they fail.