- profilebase - web config profile properties

ASP.NET built in user profile vs. old stile user class/tables (6)

Check out this question...

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

The first hint that the built-in profiles are badly designed is their use of delimited data in a relational database. There are a few cases that delimited data in a RDBMS makes sense, but this is definitely not one of them.

Unless you have a specific reason to use ASP.Net Profiles, I'd suggest you go with the separate tables instead.

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

How do you decide what should be kept in the built-in user Profile, or if you should create your own DB Table and add a column for the desired fields? 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 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 very well (it is a bit of a Matrix right now), I probably can do whatever I want if I go the table route (e.g., SQL to get all the users in the same ZIP code as the current user); I don't know if I can do the same if I use the ASP.NET profile.

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.

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.

Seems to me you have answered your own question. If your point 1 is likely to happen, then a SQL table is the only sensible option. Profiles and Membership - Custom Providers or should completely I roll my own?

I'm not experienced writing my own profile provider, but I have written my own membership provider. It's relatively easy (there are plenty of methods that you don't need to implement). In fact the only methods that seem really required are the GetUser() and ValidateUser() methods.

The only part that's a little tricky (and worth profiling) is that it seems that GetUser() gets called pretty frequently and you should think about caching the results so that you're not always hitting the database.

Use ASP.NET Profile or not?

There was an article on MSDN (now on ASP.NET that discusses how to make a Profile Table Provider. The idea is to store the Profile data in a table versus a row, making it easier to query with just SQL.

More onto that point, SQL Server 2005/2008 provides support for getting data via services and CLR code. You could conceivably access the Profile data via the API instead of the underlying tables directly.

As to point #2, you can set defaults to properties, and while this will not update other profiles immediately, the profile would be updated when next it is accessed.