少し前にカスタム プロファイル プロバイダーの例を調べましたが、今はそれを再検討しています。
私のデータベースには、aspnet 登録ウィザードを実行したときに作成されたすべての dbo.aspnet_* テーブルがあります。これらのテーブルには、aspnet_Users を指す FK 制約を持つ aspnet_Profile があります。
MyDB には 2 つのテーブルもあります。最初の dbo.ProfileData には、dbo.Profile を指す外部キー制約があります。
私が理解したいのは、MyDB のテーブルが dbo.aspnet_* のテーブルとどのように関連しているかです。MyDB のプロファイル テーブルと aspnet テーブルの間に外部キー制約 (または何らかの関係) があるべきではありませんか? 私のカスタム テーブルが aspnet によって提供されるテーブルとどのように関連しているかについての議論はすばらしいでしょう。
前もって感謝します。
私が見ることができる2つのオプションがあり、どちらも基本的に同じ結果になります。
FK from dbo.aspnet_User.UserIDto dbo.Profile.UserID、次に一意キーを定義しますdbo.Profile.UserID（のPK列として使用する場合を除くdbo.Profile）
FKdbo.aspnet_Profile.ProfileIDからdbo.Profile.ProfileID
dbo.aspnet_Userは論理的に1-1dbo.aspnet_Profileであり、同じリレーショナル整合性が得られるため、どちらのアプローチを使用するかは実際には重要ではありません。
標準のプロファイルデータテーブルを独自の実装に置き換える場合は、最初の提案を使用する方が理にかなっています。そうでない場合は、プロファイルスキーマを拡張する場合は、2番目の提案を使用してください。
編集
aspnet_Profileは標準テーブルです。標準ではSqlProfileProvider、ユーザーのプロファイルデータがシリアル化されたプロパティバッグとしてに格納されます。したがって、個別のテーブルaspnet_Profileもありません。aspnet_ProfileData
このアプローチにより、基盤となるデータベースに変更を加えることなく、さまざまなアプリケーションに合わせてプロファイルスキーマを簡単にカスタマイズでき、.NETなどのフレームワークに最適なソリューションです。欠点は、SQL Serverがこのデータに簡単にアクセスできないことです。そのため、T-SQLとセットベースのロジックを使用して、ユーザーのプロファイルデータのインデックス作成、更新、クエリを行うのがはるかに困難です。
この制限を取り除くために私が見た最も一般的なアプローチはSqlProfileProvider、アプリケーション固有のプロファイルプロパティの特定の列を持つカスタムプロファイルデータテーブルに書き込むように標準を拡張することです。このテーブルは、当然aspnet_Profileテーブルと1対1の関係にあるため、上記のように外部キーを持っています。
拡張プロバイダーの役割は、プロファイルの書き込み中に特定のプロファイルプロパティを列にプロモートし、プロファイルが取得されるときに列を読み取ることです。
これにより、拡張プロバイダーが特定のプロパティについて「認識」していない標準実装にフォールバックする方法を知っている限り、必要に応じてストレージソリューションを組み合わせることができます。
標準のメンバーシップテーブルをそのままにして、必要に応じて適切な外部キーを持つ新しいテーブルを使用して拡張し、適切なプロバイダーをサブクラス化して、プロバイダーメソッドを独自の実装でオーバーライドする（可能な限り基本実装を呼び出す）のが常に最善だと思います。 ）。