While Loop

I only recommend this basic approach if your domain (the number of codes possible) is much, much larger than the number of codes generated.

I assume that your "codes" are pseudo-random generated values.  If you're going to try to create 100,000 codes for 50,000 people, you DO NOT WANT to generate codes randomly and see if they're already in the database.  Half your codes are used at the end, then it becomes how many times do you flip a coin before it finally comes up tails?  Twice?  Fifteen times?  Though unlikely, you could theoretically need to retry several thousand times. 

If you're trying to generate 50,000 codes for 50,000 people, the last code would only have 1 in 50,000 odds of success of working the first time, and only 1 in 50,000 odds of working the second time, or the third, or any time after that.  You still have less than 20 percent chance of having found it after 10,000 attempts.

If you're going to go the route of generating codes at random, then trying again if you have a match, you need to make the chances of a match astronomically slim, something like 10,000 times as many possible values as there are values that are actually being used.  You'll still have to be capable of withstanding a performance hit of several retries in a row.  No matter how unlikely it becomes to retry 50 times before you find an unused code, it always remains possible.

Exact expectations placed on random numbers and performance just in general don't go together.  The most inefficient sorting algorithm ever invented, which can theoretically take an infinite amount of time to process, is the most inefficient ever because it uses randomization.  See Bogosort.

I only recommend this basic approach if your domain (the number of codes possible) is much, much larger than the number of codes generated.

I assume that your "codes" are pseudo-random generated values.  If you're going to try to create 100,000 codes for 50,000 people, you DO NOT WANT to generate codes randomly and see if they're already in the database.  Half your codes are used at the end, then it becomes how many times do you flip a coin before it finally comes up tails?  Twice?  Fifteen times?  Though unlikely, you could theoretically need to retry several thousand times. 

If you're trying to generate 50,000 codes for 50,000 people, the last code would only have 1 in 50,000 odds of success of working the first time, and only 1 in 50,000 odds of working the second time, or the third, or any time after that.  You still have less than 20 percent chance of having found it after 10,000 attempts.

If you're going to go the route of generating codes at random, then trying again if you have a match, you need to make the chances of a match astronomically slim, something like 10,000 times as many possible values as there are values that are actually being used.  You'll still have to be capable of withstanding a performance hit of several retries in a row.  No matter how unlikely it becomes to retry 50 times before you find an unused code, it always remains possible.

Exact expectations placed on random numbers and performance just in general don't go together.  The most inefficient sorting algorithm ever invented, which can theoretically take an infinite amount of time to process, is the most inefficient ever because it uses randomization.  See Bogosort.