0

Asp.net Membership Providership Sqlを調べて、自分のニーズに合っているかどうかを判断し、いくつかの基本的な質問があります。

たくさんのテーブルを作成しているようですが、その多くは必要ないと思います。必要なアプリケーションは1つだけで、役割管理は必要ありません。未使用のテーブルを削除できますか、それともそのままにしておく必要がありますか？

SQLメンバーシッププロバイダーで作成されたユーザーにレコードを関連付けることができる別のテーブルが必要です。このユーザーの主キーとして「Membership.GetUser.ProviderUserKey.ToString（）」を使用しても安全ですか。そうだと思いますが、それを管理しているのはAsp.Netであるため、自分では制御できないものに依存しているように感じます。

また、統計を取得するためにユーザーでログインせずに、データベースに直接アクセスします。aspnet_Users.UserId（table.field）を使用して、データベースに対してSQLクエリを実行しても安全ですか。私が恐れているのは、フレームワークの更新後に突然、Asp.Netがテーブルのレイアウトなどを変更することだと思います。

4

2 に答える 2

1

ProviderUserKey は、参照する必要があるものをすべて格納することを目的としているため、追加のユーザー情報を格納するために独自のデータベースにレコードへのキーを格納できます。使用する機能が触れない限り、無関係なテーブルを削除しても問題ないと思います。

私はそれがaspnet_applications、aspnet_usersに触れることを知っています...

最後の手段として、MembershipProvider から継承するクラスを作成することで、いつでも独自のカスタム メンバーシップ プロバイダーを作成できます。

于 2010-02-12T16:53:01.557 に答える
1

明らかに、テーブルを生成したら、好きなことを行うことができますが、その影響を考慮する必要があると思います。メンバーシップ プロバイダー フレームワークは非常にうまく機能し、広く実装されています。それらの実装を使用する場合は、それを使用して、必要な部分を使用し、残りはそのままにしてください。

彼らは、破壊的な変更を私たちに伝えるか、破壊的な変更を行わないようにするために、変更を加えるとき/場合に非常に注意を払います。

フレームワークを使用すると、提供されているメソッドの多くをオーバーライドできます。または、独自のカスタム プロバイダーを作成して、すぐに使用できる実装に大きく基づいて作成することもできます。

于 2010-02-12T16:29:00.767 に答える