Use ASP.NET Profile or not?

views:

answers:

+2 Q:

Use ASP.NET Profile or not?

I need to store a few attributes of an authenticated user (I am using Membership API) and I need to make a choice between using Profiles or adding a new table with UserId as the PK. It appears that using Profiles is quick and needs less work upfront. However, I see the following downsides:

The profile values are squished into a single ntext column. At some point in the future, I will have SQL scripts that may update user's attributes. Querying a ntext column and trying to update a value sounds a little buggy to me.
If I choose to add a new user specific property and would like to assign a default for all the existing users, would it be possible?

My first impression has been that using profiles may cause maintainance headaches in the long run. Thoughts?

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.

Tor Haugen 2010-05-14 22:15:46

Check out this question...

http://stackoverflow.com/questions/1683/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.

kervin 2010-05-14 22:17:53

badly designed? how would YOU design a dynamic profile system that can work out of the box simply by modifying a configuration file... in 2003? I would say that there were some pretty smart people that put it in place and that your 'hint' is misinformed.

Sky Sanders 2010-05-14 22:54:43

@code poet: down votes aren't for disagreeing with opinions :) It's my opinion that putting delimited data in a single column for generic profile data is a bad design. There are well known table designs that address this concept.

kervin 2010-05-14 23:31:36

' If you see misinformation, vote it down. ' http://stackoverflow.com/faq - flatly characterizing ASP.Net profiles as badly designed is misinformation and may unnecessarily divert some with less experience from using the very simple facilities provided by the default providers to unnecessarily complex aftermarket specialized solutions. Again, how would you provide the same functionality, that is OOB ability to provide transient, dynamic user meta using only configuration?

Sky Sanders 2010-05-14 23:53:59

And I would have to say that your conclusion is also bad advice. Unless you have a specific reason *not* to use the default provider, it is always better to not reinvent the wheel.

Sky Sanders 2010-05-14 23:59:32

+2 A:

There was an article on MSDN (now on ASP.NET http://www.asp.net/downloads/sandbox/table-profile-provider-samples) 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.

Jonathan Bates 2010-05-14 22:23:57

Can you comment on the flexibility and performance of the 'Profile Table Provider' for a large user base?

DotnetDude 2010-05-14 22:43:24

+1 this is the way to go if you have less than trivial profile data and/or access requirements. Performance is much better with a table based provider due to the serialization/deserialization required by the default dynamic profile implementation.

Sky Sanders 2010-05-14 22:50:47

@DotNetDude: I am afraid it depends on your definition for large. As to flexibility, by using a provider, developers get to continue use the Profile API in code. This makes developing solutions google-able (or StackOverflow reasearch-able, if you rather) in the general sense instead of some custom one-off.Performance measures would also have to take into account the original intent of point #1 of the question: having the profile data available in an easier to query format than the standard Profile db schema. The table provider gains some points there.

Jonathan Bates 2010-05-15 00:44:18

ansaurus

tags:

views:

answers:

Use ASP.NET Profile or not?

related questions