6

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:

  1. 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.
  2. 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?

DotnetDude
  • 11,617
  • 35
  • 100
  • 158
  • +1 - better question. shows initiative in that you have examined the issue yourself and still have questions. – Sky Sanders May 15 '10 at 00:04
  • I've come up with a way to query the default profile provider data that works very well for me: http://stackoverflow.com/a/13747590/64334 – Ronnie Overby Dec 06 '12 at 16:15

3 Answers3

3

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
  • 1,835
  • 14
  • 22
  • Can you comment on the flexibility and performance of the 'Profile Table Provider' for a large user base? – DotnetDude May 14 '10 at 22:43
  • +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 May 14 '10 at 22:50
  • @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 May 15 '10 at 00:44
0

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
  • 19,509
  • 9
  • 45
  • 63
-1

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.

Community
  • 1
  • 1
kervin
  • 11,672
  • 5
  • 42
  • 59
  • 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 May 14 '10 at 22:54
  • @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 May 14 '10 at 23:31
  • ' 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 May 14 '10 at 23:53
  • 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 May 14 '10 at 23:59