ASP.NET built in user profile, Vs old stile user class/tables

Question

I am looking for the spiritual guidance of what is the best practice around the use of Profile feature in ASP.NET.

How do you decide what should be kept in the built in user Profile, or if you should just go and create your own DB Table and add a column for that? For example, a user has a zip code, should I save the zip code in my own table, or should I add it to the web.config xml profile and then access it via the user profile ASP.NEt mechanize?

The pros/cons I can think of are that since I don't know the profile so well, (it is a bit of a Matrix right now) I probably can do whatever I want if I go the table route (like, SQL to get all the users in the same zip code as the current user), I don't know ifI can do the same if I use the ASP.NET profile.

Answer 1

In my experience its best to keep an the info in the profile to a bare minimum, only put the essentials in there that are directly needed for authentication. Other information such as addresses should be saved in your own database by your own application logic, this approach is more extensible and maintainable.

Answer 2

I think that depends on how many fields you need. To my knowledge, Profiles are essentially a long string that gets split at the given field sizes, which means that they do not scale very well if you have many fields and users.

On the other hand, they are built in, so it's an easy and standardized way, which means there is not a big learning curve and you can use it in future apps as well without needing to tweak it to a new table structure.

Rolling your own thing allows you to put it in a properly normalized database, which drastically improves performance, but you have to write pretty much all the profile managing code yourself.

Edit: Also, Profiles are not cached, so every access to a profile goes to the database first (it's then cached for that request, but the next request will get it from the database again)

If you're thinking about writing your own thing, maybe a custom Profile Provider gives you the best of both worlds - seamless integration, yet the custom stuff you want to do.

Answer 3

Ive only built 2 applications that used the profile provider. Since then I have stayed away from using it. For both of the apps I used it to store information about the user such as their company name, address and phone number.

This worked fine until our client wanted to be able to find a user by one of these fields. Searching involved looping through every users profile and comparing the information to the search criteria. As the user base grew the search time became unacceptable to our client. The only solution was to create a table to store the users information. Search speed was increased immensely.

I would recommend storing this type of information in its own table.

Answer 4

Other information such as addresses should be saved in your own database by your own application logic

OK, so this seems to be the way to go, can anyone tell me how to best link the asp_ user tables to this new table? should I use the userName in asp_ table as the link, the userID (that ugly guid I don't know how to even get) or what?

Answer 5

user profile is a nice clean framework for individual customization(AKA. Profile Properties). (e.g. iGoogle) the problem of it is its not designed for query and not ideal for data sharing to public user.(you still would be able to do it, with low performance)

so, if you want to enhance the customized user experience, user profile would be a good way to go. otherwise, use your own class and table would be a much better solution.

Answer 6

I think it is better off using it for supplementary data that is not critical to the user that is only normally important when that user is logging in anyway. Think data that would not break anything important if it was all wiped.

of course thats personal preference but others have raised some other important issues.

Also very useful considering it can be used for an unauthenticated user whose profile is maintained with an anonymous cookie.