I did not realize that. I just saw you mentioned it earlier as well, but I might have missed that post before.
If your website will heavily make use of forums, and/or prgramability that relies lots on the profiles in order to get things done (mine will), I would recommend actually avoiding relying so much on the "traditional" setup asp.net offers.
Personally, I feel that it would be preferable to have certain properties of the userproile easily accessible in a proper column, rather than in an obscure string as it obviously is (I only now checked out the way the profiles are stored, and while this works fine for a whole bunch of user-related information that I most likely will not be accessing frequently, there are certain properties I would want to have some more control over).
Therefore, I guess I will either be adding some columns to the profile table, or use an additional table, which in turn will make it far more easy to keep things working, but allowing more control over the data I need (frequently changing data like the postcount would for instance be something I will most likely use this construction for).
I found this while looking into ways to extend the userprofile, and to me it seems like a very neat way to still stick to the standard membership and profile options asp.net offers, while allowing easy extension:
I apologize for missing your reply earlier, and perhaps coming across stubborn. I'm just a big believer of using objects what they were created for, and I still think that using a trigger would be the best technical solution for what you described ;) If the TBH solution doesn't foresee using a trigger to do this, I'd personally opt for expanding the framework to suit my needs :)