View Single Post
  #3 (permalink)  
Old August 1st, 2008, 04:33 PM
Scott663 Scott663 is offline
Authorized User
Join Date: Mar 2007
Location: , , .
Posts: 39
Thanks: 0
Thanked 1 Time in 1 Post

Lee, thanks for the excellent info. I've been using the Membership provider for a while now, but never took the time to fully understand it until now. I did not realize the user table had an identity field, but now I see the "ProviderUserKey" property. All the examples I've studied (including TBH) always used the username as a reference key, instead of the UserKey.

My comment about caching was not about caching the Membership data itself, but the fact that when I cache other data (forums, ratings, etc...) it seemed like a waste of recources to use reference key fields populated with usernames (~256kb) as opposed to an identity field (4kb). I hope this makes sense now?

Thanks for the link to Scott Guthrie's blog. His blogs are always excellent, and this article seems to address what I'm trying to do.

As far as understanding why the profile is serialized, I just figured it was so that developers could easily add custom profile properties without touching the DB and Membership entity. This is only a guess thought, which means I'm probably wrong...

Thanks again for your valuable input!