Asp.net profile provider

I know there are already some questions on this topic on the site ...

I'm just trying to figure out if the ASP.NET Profile provider can be used with a huge traffic website?

The way I see it has been laid out ineffectively. You store the property name (which is a string) and the property value (which is also a string). If you are just trying to keep the same age in the profile, you are unnecessarily storing the row "age" in the database over and over again, then how with a self-created table you can just add the age with the column name and no redundancy?

(I'm just trying to make sure I haven't missed anything because I'm pretty new to this.)

+2


source to share


3 answers


The profile provider deliberately uses the EAV ( Entity-Attribute-Value ) design , since profiles in general very often have a sparsely populated schema - there are many potential attributes, but only a few will be used for a given single entity, and some of them will vary widely from one entity to another.

Let's use a completely arbitrary example - let's say only one in ten of your users wants to provide their age. Making a column looks more like a waste now, doesn't it?



But what if your application makes age mandatory? Ok, this column fills in for everyone. But what if you need to make a profile note, "the user no longer wants to see this obscure dialogue." Do you really need a column for every single dialog in your application, does the user want to see it? Probably no. When you get into the small one-off parts of any significant application, EAV actually becomes a more economical choice.

In general, it scales very well (much better than you probably think). It doesn't matter in a specific case - as always, use what works and fix performance issues when they arise. Regardless of the profile provider's scalability limits, you'll know when they hit. I guarantee two things: (1) you will have to fix a lot of other performance problems that you did not expect before you fix it; and (2) if your site is getting enough traffic to break provider profiles, that's a good problem.

+8


source


I agree with Rex M as long as you don't need to do things like sort all of your users by age or do other things with aggregate profile data. Then you might consider skating on your own. But for simply storing properties that you get here and there separately, Rex M is the right one.



0


source


I know what you mean. Wouldn't it make sense to bring the service provider table to another table that has columns with required fields? or do you think the overhead of merging won't make it costless?

0


source







All Articles