I've seen a number of references to using GUIDs as the primary keys. This would avoid the problem of someone "guessing" a PK. However, the (small) overhead in creating the GUID, and the increased storage requirements (afterall, a GUID is a string) would probably be slightly slower than integers.
That said, when it comes to security, you have to ask how important the data is and then implement security procedures of the appropriate level. Afterall, doing retinal scanners and voice recognition to protect something like resumes would be overkill. My thoughts.... Shawn Grover -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 1:53 PM To: CF-Talk Subject: RE: Hacking" a shared SQL server > 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. ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
