> I'm sure someone can give me a good example of why to not use sequential > primary keys, however. So I am ready to learn why this might not be as > secure as using a hash or GUID, given my methodology and security practices > for handline this data, of course. Just because someone can look at > ProductID 10 by changing the current one in the URL doesn't really bother > me. If you don't want an end-user to look at ProductID 10, then it should > be secured so it can't be gotten to by that user unless they have the > appropriate permissions, meaning that you can't hope that the user didn't > get a link to ProductID 10 pasted in an email or copied from another > employee's open browser window, whether the ProductID was hashed, GUID'd, or > not.
Agreed. Although the cross-our-fingers-and-hope-they-don't-guess-the-right-ID method can be a deterrent, I don't believe it should ever be used for any kind of substantial security. That's one reason why I still use sequential IDs. Most of the sites I work on do not need any kind of replication or merging of data, which is where I believe GUIDs come in handy. Sure, it's good to build sites scalable where they can change from a hundred rows in a table to a million, but there's also something to be said for making sites practical. Sequential, numeric IDs are simple and easy to work with. GUIDs do not add *that* much difficulty, but they still add some -- especially for any lesser experienced developers that you work with. Ben Johnson Hostworks, Inc. ______________________________________________________________________ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm 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
