Voucher Number Generation logic

You should generate number in advance, fill in the table and then just take it when you need.
But I would recommend to store different length of vouchers in different tables and use the unique key. 

Hi,
Rnd function in Visual studio is the option to get random number. And you need to validate if the same voucher number is already existing or not. If it exists, you can re-generate another random number.

Generating random numbers and checking the database for pre-existence is both an expensive and insecure approach.

Instead, issue ticket numbers as follows:

First n digits:  Sequentially assigned number
Next h digits:  Hash 1 of at least 6 of the first n digits plus a salt
Next i digits:  Hash 2 of at least 8 the first n+h digits plus a salt
Last digit:  Quick check digit

https://en.wikipedia.org/wiki/Check_digit

Using sequentially assigned numbers eliminates both random number generation and database pre-existence lookup.  Hashing, then hashing again throws up two barriers against counterfeiting.  This quickly generates long (but not unreasonably long) unique IDs which can also be quickly validated.

You must generate your own unique hash functions for hash functions 1 and 2 and keep the functions secret.  The hash functions must be quick but so difficult that they cannot be analyzed numerically.

Dear Dr. Klahn ,

Do you have any pseducode to do this could be in SQL server or C#.
We have some configuation at product level for voucher generation like Alphabets (how many to include), Numbers (how many to include), Length of the code (8,9,10,11 etc till 20)

As Máté mentioned, if the slowness is around random number generation...

You should generate this outside of any SQL + test to determine if your system has enough entropy to keep up with random number generation requirements.

I'll describe this problem can be easily solved in Linux, which you'll convert to Windows equivalents.

1) Biggest challenge, speed of random number generation, depends amount of entropy/randomness your system maintains.

I run rng-tools, so if entropy ever drops to low, rngd (always running) produces more entropy.

This results in rapid generation of long random strings where any collisions (non-uniqueness) is... improbable...

If you're interested in how rngd works, you can search online for long discussions.

2) Time to generate random number should be near instantaneous.

On Linux, using a brain dead pipeline in PERL running many heavy weight processes...

my ($pass) = `tr -dc 'A-Za-z0-9' < /dev/urandom 2>/dev/null | head -c$bytes`;

Select allOpen in new window

Produces this rough speed estimate.

net14 # random --speed
# SPEED: random: generate_random(): 12 seconds to generate 5000x 128 long random numbers (roughly 416.67 numbers/second)

Select allOpen in new window

This is a lot of randomness, handed out quickly. Likely this number will be much higher if the pipeline was optimized.

3) Database INSERT should also be near instant, if the voucher field is correctly indexed.

Said differently, using a schema tooled for speed, INSERTing voucher row 1 + voucher row 1,000,000+ should take almost exactly the same amount of wall clock time.

4) Go through each of these items + ensure they're all correct.

Regards #1, depending on exactly how you arrange to keep your entropy high when generating many random numbers in rapid succession, each random number request could easily block, waiting on your system primitives to increase entropy to an acceptable level, before returning.

To check this write a simple script to generate random numbers, then test speed of your system random number generation.

5) If worse comes to worse, you could always write a simple Linux API system, to return you blocks of 100x or 1000x or however many you might require... if you can't figure out how to generate random numbers without blocking on Windows.

My guess is Windows has some sort of primitive system like Linux rng-tools + /dev/urandom.

Random Tip: The pipeline I use is specifically crafted to only return alphanumeric random strings, which means cut + paste works as expected.

If you allow any other characters, click to select the string changes to a click + drag operation.

Sticking with alphanumeric random strings reduces the number of support tickets generated, when people double click, rather than click + drag to select the string.

I don't think you want outsiders involved in generating your hash function algorithms, which must be kept completely secret.  Any text on data structures will offer some jumping-off points for hash functions; from there on let your imagination rule.

Example:  Exponentiation to a fractional exponent and picking the nth, n+2th and n+6th digits of the result as part of the hash.