for tables with small records, this might be ok. But think about a transaction table - potentially hundreds of transactions a day. For the first bit, this might work well. But eventually your system will bog down while it tries to find an un-used ID.
Also, to generate your random number, you have to predetermine the upper limit (numbers from 1 to 1,000,000 say, or more even). This will limit your system to X number of records (whatever your upper limit is). So, in larger applications random numbers are probably not the best solution. Shawn Grover -----Original Message----- From: Michael Ross [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 3:23 PM To: CF-Talk Subject: RE: Hacking" a shared SQL server Coming out of left field here as I haven't read everything but what about in your code getting a random number, checking to make sure its not in your table then insert it. Just run a loop. >>> [EMAIL PROTECTED] 06/06/02 03:52PM >>> > Actually there is nothing wrong with using an integer for a primary key. > The trick is to make sure they aren't in sequence, so that people can't > guess other keys. Matt, Do you have any methods for creating non-sequenced integer primary keys that aren't a performance hit? I can think of two: -- Have a single table with a bunch of integers in random order. This seems a bit cumbersome to me, but definitely possible. -- Have your primary keys based off an algorithm. Technically, still a sequence, but definitely not as easy to figure out. You'd have to make sure this was implemented site-wide. Perhaps a stored procedure to pull the next based on the previous one. Ben Johnson Hostworks, Inc. ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
