ASP.NET のプロファイル機能の使用に関するベスト プラクティスに関するガイダンスを探しています。
組み込みのユーザー プロファイルに何を保持する必要があるか、または独自のデータベース テーブルを作成して必要なフィールドの列を追加する必要があるかどうかをどのように決定しますか? たとえば、ユーザーが郵便番号を持っている場合、郵便番号を独自のテーブルに保存する必要がありますか?それとも、それを web.config xml プロファイルに追加して、ユーザー プロファイルの ASP.NET メカニズムを介してアクセスする必要がありますか?
私が今考えている長所/短所は、私はプロファイルをよく知らないので (今はちょっとしたマトリックスです)、テーブル ルートに行けば、やりたいことは何でもできるということです (例:現在のユーザーと同じ郵便番号のすべてのユーザーを取得する SQL)。ASP.NET プロファイルを使用した場合に同じことができるかどうかはわかりません。
プロファイル プロバイダーを使用するアプリケーションを 2 つだけ作成しました。それ以来、私はそれを使用することを避けてきました。どちらのアプリでも、会社名、住所、電話番号などのユーザーに関する情報を保存するために使用しました。
クライアントがこれらのフィールドのいずれかでユーザーを検索できるようにするまで、これはうまくいきました。検索には、すべてのユーザー プロファイルをループして、情報を検索基準と比較することが含まれていました。ユーザーベースが拡大するにつれて、検索時間はクライアントにとって受け入れられなくなってきました. 唯一の解決策は、ユーザー情報を格納するテーブルを作成することでした。検索速度が大幅に向上しました。
このタイプの情報は、独自のテーブルに格納することをお勧めします。
ユーザー プロファイルは、個々のカスタマイズ (AKA. プロファイル プロパティ) のためのきれいなフレームワークです。（例：iGoogle）それの問題は、クエリ用に設計されておらず、パブリックユーザーへのデータ共有には理想的ではないことです（パフォーマンスが低くても実行できます）
そのため、カスタマイズされたユーザー エクスペリエンスを強化したい場合は、ユーザー プロファイルが適しています。それ以外の場合は、独自のクラスとテーブルを使用する方がはるかに優れたソリューションです。
私の経験では、プロファイルの情報を最小限に抑え、認証に直接必要な要素のみをそこに入れるのが最善です. アドレスなどのその他の情報は、独自のアプリケーション ロジックによって独自のデータベースに保存する必要があります。このアプローチは、より拡張性と保守性に優れています。
それは、必要なフィールドの数に依存すると思います。私の知る限り、プロファイルは本質的に、指定されたフィールド サイズで分割される長い文字列です。つまり、多くのフィールドとユーザーがいる場合、プロファイルはうまくスケーリングされません。
一方、それらは組み込まれているため、簡単で標準化された方法です。つまり、大きな学習曲線がなく、新しいテーブル構造に微調整する必要なく、将来のアプリでも使用できます。
独自のものを作成すると、適切に正規化されたデータベースに配置できるため、パフォーマンスが大幅に向上しますが、ほとんどすべてのプロファイル管理コードを自分で作成する必要があります。
編集：また、プロファイルはキャッシュされないため、プロファイルへのすべてのアクセスは最初にデータベースに送られます（その後、そのリクエストに対してキャッシュされますが、次のリクエストではデータベースから再度取得されます）
独自のものを作成することを考えている場合は、カスタム プロファイル プロバイダーを使用すると、両方の長所を活用できます。
とにかくログインしているときにのみ通常は重要な、ユーザーにとって重要ではない補足データに使用する方がよいと思います。すべて消去しても重要なものは壊れないデータと考えてください。
もちろん、それは個人的な好みですが、他の人は他の重要な問題を提起しています.
また、プロファイルが匿名 Cookie で維持されている認証されていないユーザーに使用できることを考えると、非常に便利です。