> Postgres handles this gracefully with it's "SEQUENCES" feature. After > user1 calls up the form, user2 will be returned ID 12 rather than 11. So > there's no possible conflict like that.
Okay. I'm just starting to play with with Postgres, so here are a few questions (that presumably will have some value regarding the original question): -Does this work on a per-connection basis (i.e. it'd require mod_perl), or database-wide (CGI is fine) -I'm assuming nothing is "freed", so once the sequence hits it's end, that's it? (which, granted, could be 30 years) > No, there are just some gaps in the unique ID sequence, which is fine > with me. (and would happen anyway later when some items got deleted). > > Brett's idea about using a bit of random data also seemed reasonable for > a general case. I like the idea of combining them. The random data idea has two parts: the value has no use except to check for duplicate submissions, and it shouldn't repeat in the db. The problem is that there is a small chance it will repeat. The sequence works fine, but I'm inclined to dislike anything that further fragments my primary key data and shortens the time until my idspace runs out. I know MySQL supports a serial type that can be told to cycle back to 1 when it runs out, I'm sure the other databases do. If you have a submission_check sequence that does just as Mark suggested, but uses this value rather than the ID to check: -You will know about duplicate submissions -There will be no key duplication unless you experience more than submission_check sequences within your warning_window, and you can easily set that to an acceptable risk. -Your primary key space is not depleted. --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
