I always include a column ID with an auto increment feature in my databases. Is there any reason why I wouldn't want to use that as the users ID for a social networking site. The ID would be known to public and used in URL's and what not. Figured that would be easier than adding another function to create a separate unique ID for members. Just wanted to see if anyone else found any problems with this before I use it in my code.
The id itself would leak information that would allow a third party to approximate the date he or she registered in your site. So if Alice is friends with Bob and knows that she registered last year and he followed 3 days later and that her id is 100 and his is 150, she will know that Carol, who is not her friend, registered in your site back then and not 'just recently' as Carol claimed, trying to find an excuse as to why she is not 'friends' with Alice in your social media site!
Is this a problem? You will decide for yourself, but personally I would prefer to be a bit professional/paranoid (these two often go together, whatever that means for our profession!) and avoid including auto-increment ids in the URL where there is even the slightest security / privacy concern. Or at least, advise you to be :-)
If you do decide to take the path of Virtue, you may need to consider that other ids also leak information (e.g. Alice will know Carol earlier than what she claimed if she finds out her profile id is a smaller number than Bob's). So, while it may seem that you could add, say a GUID column, and use it as a secondary id, one that would be safe to include in URLs, you might be better off just switching from autoincrement ids to using GUIDs. (More on GUIDs here: http://en.wikipedia.org/wiki/Globally_unique_identifier)
Hope that helps :-)