2

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

I am just trying to understand if it's safe to use ASP.NET Profile Provider with a website with huge traffic?

The way I see it, it's laid out inefficiently. You store property name (which is a string) and property value (which is a string too). If you are just trying to store even age in the profile, you are unnecessarily storing the string "age" in the database over and over whereas with a self-created table, you could just add a column titled age, and no redundancy?

(I am just trying to make sure I am not missing something about it, because I am fairly new to it.)

4

3 に答える 3

8

プロファイルプロバイダーは意図的にEAV（Entity-Attribute-Value）設計を使用します。これは、プロファイルは一般にまばらに配置されたスキーマを持っているためです。つまり、多くの潜在的な属性がありますが、特定の単一エンティティに使用されるのはごくわずかです。使用されるいくつかは、エンティティごとに大きく異なります。

完全に恣意的な例を使用してみましょう。たとえば、ユーザーの10人に1人だけが年齢を提供したいとします。そのカラムを作ることは今では無駄のように見えますね？

しかし、アプリケーションで年齢が必須になった場合はどうなりますか？OK、その列はすべての人に入力されます。しかし、プロファイルに「ユーザーはこのあいまいなダイアログをもう見たくない」とメモする必要がある場合はどうでしょうか。ユーザーが表示したいかどうかにかかわらず、アプリケーションのすべてのダイアログに列が本当に必要ですか？おそらくそうではありません。重要な範囲のアプリケーションの1回限りの詳細に入ると、EAVは実際にはより経済的な選択になります。

一般的に、それは非常にうまくスケーリングします（おそらくあなたが思っているよりはるかに良いです）。具体的には、問題ではありません。いつものように、機能するものを使用して、パフォーマンスの問題が発生したときに修正します。プロファイルプロバイダーのスケーラビリティの制限が何であれ、それらにぶつかったときにわかります。私は2つのことを保証します-（1）修正する前に、予期していなかった他の多くのパフォーマンスの問題を修正する必要があります。（2）サイトがプロファイルプロバイダーを壊すのに十分なトラフィックを獲得している場合、それは良い問題です。

于 2009-09-02T05:47:32.067 に答える
0

すべてのユーザーを年齢で並べ替えたり、集合体プロファイルデータを使用して他の手順を実行したりする必要がない限り、RexMに同意します。次に、自分でローリングすることを検討できます。しかし、ユーザーごとにあちこちでアクセスするプロパティを保存するだけの場合は、RexMが適しています。

于 2009-09-02T05:59:01.823 に答える
0

私はあなたが何を意味するか知っています。プロファイル プロバイダーのテーブルに、必須フィールドを持つ列を持つ別のテーブルを追加するのは理にかなっていると思いませんか? または、結合のオーバーヘッドは価値がないとは思いませんか?

于 2009-09-02T22:21:46.457 に答える