Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Suggestions for random candidate key generation methodol
Message
 
 
To
09/05/2004 13:35:39
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00902286
Message ID:
00902303
Views:
25
This message has been marked as the solution to the initial question of the thread.
Nancy,

We needed to provide a random value that could be emailed out to people but that could still be used to uniquely identify them, but that could not be spoofed to access another person's data, ie you couldn't just increment the value in the URL to the next number and be the next person. We decided a 10 random character code 36^10 (A-Z, 0-9) = 3,656,158,440,062,976 combinations = ~ 600,000 codes per person on the planet was adequate.

Since random numbers on digital computers are not really random at all, you should generate the sequence all at once and then just use numbers from that pool and delete them as you use them. Otherwise you have to store like 3 values: the key and the 2 components that generated it so that you can grab the key and then calculate the next one and store the 2 components again. Overall that's more work than just generating the pool to begin with. if your pool ever gets completely consumed you can restart the generation routine from the exact same starting place and ignore the first N results and then start saving to the pool. If you generate 10 times the expected number of keys needed you are probably safe enough.

>I need to generate 7-digit, unique, random numeric quasi-serial number. I'll generate these serial numbers (SN) within a buffered transaction that may or may not be finalized. So, the SN generated won't be written to disk right away. Therefore, I can't use the usual primary key routine most of use. I want to find an efficient system that won't add any (!) processing time to the transaction overall.
>
>I can keep a table of just serial numbers generated and not reuse any that are in that table. However, it's possible that a number will be generated but not used.
>
>I could, when I finalize the transaction, delete the unused SN record.
>
>These sorts of transactions aren't frequent, but I'd like to be as efficient as possible. Plus, I was just sort of interested in the complexity using randomly generated numbers in addition to generating them in buffered transactions adds to using the usual PK routines.
df (was a 10 time MVP)

df FoxPro website
FoxPro Wiki site online, editable knowledgebase
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform