Creating Unique Reference Number Strategies

Question

Hrm ... here, where my CS knowledge ceases to know me. I want to write an algorithm that generates a unique reference number.

I do not want to use sequential numbers because they pose a security risk, and I want to use alphanumeric. The link will have a minimum and maximum length. (I can not use the GUID for too long)

Ideally, I don't want to ask for my persistence level to see if the ref file has been used before.

What strategies can be used?

Answer 1

If you are concerned about security risks, you need a cryptographically secure random number generator. You should be able to tell how many bytes you want (i.e. how much time can be).

Answer 2

If this number will be called people, I recommend that you follow these recommendations in your decision:

What is the best format for customer number, order number?

If you cannot synchronize with the database to find out what will be the next number, and you cannot use a GUID or a relatively long random string, then you need to include some local value in the identifier.

for example, if all clients are on a known network, you can complete each number in each block D of the client IP address.

Or, if customers need to log in, and each user can log in only once at a time, you can include their user ID in the number somewhere.

Answer 3

I take a hit in the dark, but ... you want a random value to be unique, but less than 16 bytes. Your best bet is still the GUID, which is only 16 bytes .... You want to use alphanumeric characters to ... some parameters.

Use a GUID, but encode it. base64 looks like 7QDBkvCA1 + B9K / U0vrQx1A, which is 22 bytes, which is even longer than the native Guid ... but shorter than a typical string representation.

See text encoding here: http://en.wikipedia.org/wiki/Globally_Unique_Identifier

Another option would be a Guid hash, but you will lose some uniqueness, so what is your level of tolerance here for non-historical items?

===========

Assuming you have one process that is inserted into the table, you can emlpoyee the HiLo algorithm and be sure that you do not need to hit the DB every time. You just saved the last high value in your memory ... when you started the process, you would go in dB to find out where you left off: What is the Hi / Lo algorithm?

I'm still saying that Guid is your best bet .... 16 bytes are not bad and will be as small as most alphanumeric solutions you came up with.

Answer 4

One way could be to create numbers based on a smaller subset of numbers. For example, you can use a binary sequence to generate based on godel numbering. For example, mapping 000 to 111 on 5z, 3y, 2x gives 0, 2, 3, 6, 5, 10, 15, 30.

Of course, this is too simplistic. But by repeating the salt numbers to create the reference numbers, you won’t need to track the reference numbers at all. Provided, or of course, you were pretty sure that you didn't have to consider conflicts.

Answer 5

If possible, in your application / environment, have you thought of adding time as part of a pseudo-random generated number?

i.e. microtime () + rand (10000,99999)

Answer 6

I do this in a production system with success:

• Take the current time (UTC, accurate to microseconds)
• Process id, thread id
• Your computer name
• Salt value (basically just a string unique to your program)
• Random value (preferably PRNG cryptographic class)

Put this in memory, either as a string, or in an XOR value together or something like that. Then:

• Hash it, for example. SHA-1
• Make mod N on the resulting number to reduce the output by N bytes
• Convert to hex or something printable if you need it.

Just remember that reducing UID to N bytes increases the chance of a UID collision.

All of the input in the first list is designed to provide a unique hash base if you have a cluster of many computers. You can omit some of them, but you must be sure that it contains something that makes it different for each computer on which you will generate a UID.

Answer 7

Reduce the GUID to the size you need.

If you generate numbers, if they are not random and huge, you better not check if they were used in any case.