asp.net - ASP.NET で認証されたユーザーを参照するには、ユーザー名またはユーザーの ID を使用する必要がありますか?

Question

そのため、私の単純な学習 Web サイトでは、組み込みの ASP.NET 認証システムを使用しています。

彼のzip、DOBなどを保存するためにユーザーテーブルを追加しています。私の質問は次のとおりです。

新しいテーブルでは、キーはユーザー名 (文字列) またはユーザー ID である必要があります。ユーザー ID は、asp_ tables.
その醜いGUIDを使用することがベストプラクティスである場合、それを取得する方法を知っている人はいますか? 名前ほど簡単にはアクセスできないようです ( System.Web.HttpContext.Current.User.Identity.Name)
ASP.NET 認証で提供される GUID フィールドと userName フィールドのどちらも使用しないことをお勧めする場合、ASP.NET 認証を使用するにはどうすればよいですか? 私が気に入っているオプションの 1 つは、ユーザーの電子メールアドレスをログインとして使用することですが、ASP.NET 認証システムでユーザー名の代わりに電子メールアドレスを使用するにはどうすればよいですか? (または、そこで何もする必要はありません。userName が実際にはメールアドレスであることを「知っている」と判断したのは私だけですか?

ご注意ください：

.NET で GUID を取得する方法について質問しているわけではありません。GUID の userID 列を参照しているだけですasp_ tables。
ユーザー名は ASP.NET 認証で一意です。

score 32 · Accepted Answer

言及したGUIDまたはその他の自動生成されたキーのいずれかの一意のIDを使用する必要があります。ただし、この番号はユーザーに表示されないようにする必要があります。

これの大きな利点は、すべてのコードがユーザーIDで機能できることですが、ユーザーの名前は実際にはそれに関連付けられていません。次に、ユーザーは自分の名前を変更できます（これはサイトで役立つと思います）。これは、ユーザーのログインとして電子メールアドレスを使用する場合に特に便利です...これはユーザーにとって非常に便利です（一般的なユーザーIDが人気のある場合に備えて20個のIDを覚えておく必要はありません）。

score 23 · Accepted Answer

UserIDを使用する必要があります。これは、MembershipUserのProviderUserKeyプロパティです。

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());

score 14 · Accepted Answer

ユーザー名が一意になる場合は、テーブルの主キーとしてユーザー名を使用することをお勧めします。これを行うには、いくつかの理由があります。

主キーはクラスター化インデックスになるため、ユーザー名を使用してユーザーの詳細をすばやく検索できます。
重複するユーザー名が表示されなくなります
2つの異なる情報（ユーザー名またはGUID）の使用について心配する必要はありません。
2ビットの情報を検索する必要がないため、コードの記述がはるかに簡単になります。

score 6 · Accepted Answer

ユーザーIDを使用します。ユーザー名を使用したい場合は、「ユーザー名の変更」機能を非常に高価にすることになります。

score 3 · Accepted Answer

私はPalmseyに同意しますが、彼のコードには少しエラーがあるようです。

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString());

する必要があります

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());

score 3 · Accepted Answer

UserIDを使用すると、主キーに影響を与えることなくユーザー名を変更できます。また、ユーザー名の重複を防ぐために、ユーザー名の列を一意に設定します。

UserIDではなく主にusernameで検索する場合は、Usernameをクラスター化インデックスにし、主キーを非クラスター化に設定します。これにより、ユーザー名を検索するときに最速のアクセスが可能になりますが、主にUserIdを検索する場合は、これをクラスター化されたインデックスのままにします。

編集：これは、現在のASP.NetメンバーシップテーブルにもユーザーIDを主キーとして使用するため、より適切に適合します。

score 3 · Accepted Answer

これは古いものですが、これを見つけた人にいくつか注意してもらいたいことがあります。

aspnet メンバーシップデータベースは、ユーザーレコードへのアクセスに関して最適化されています。SQL Server のクラスター化インデックスシーク (最適) は、lowerusername と applicationid を使用してレコードを検索するときに使用されます。ユーザーが最初に資格情報を送信するときに、提供されたユーザー名しか使用できないため、これは非常に理にかなっています。
guid ユーザー ID は int よりも大きなインデックスサイズを提供しますが、一度に 1 つのレコード (ユーザー) しか取得しないことが多く、断片化の観点から、読み取りの数は通常、書き込みと編集の数を大幅に上回るため、これはそれほど重要ではありません。 users テーブルに - 人々はその情報をそれほど頻繁に更新しません。
aspnet メンバーシップテーブルを作成する regsql スクリプトを編集して、ユーザー ID のデフォルトとして NEWID を使用する代わりに、パフォーマンスを向上させる NEWSEQUENTIALID() を使用できるようにします (私はこれをプロファイリングしました)。
プロフィール。「新しい学習 Web サイト」を作成する人は、車輪の再発明を試みるべきではありません。私が働いたことのある Web サイトの 1 つは、すぐに使用できる aspnet メンバーシップテーブル (恐ろしいプロファイルシステムを除く) を使用しており、ユーザーテーブルには 200 万近くのユーザーレコードが含まれていました。このように多数のレコードがあっても、select は依然として高速でした。なぜなら、最初に述べたように、データベースインデックスは、これらのレコードに対してクラスター化インデックスシークを実行するために、下げられたユーザー名 + アプリケーション ID に焦点を合わせ、一般的に言えば、SQL がクラスター化インデックスシークを実行している場合です。 1 つのレコードを見つけるには、テーブルに列を追加してデータを引き戻しすぎなければ、膨大な数のレコードがあっても問題はありません。
システムの実際のパフォーマンスと経験に基づいて、私にとって、このシステムの GUID について心配することは時期尚早の最適化です。ユーザー ID に int があるが、カスタムインデックスの設計などのためにシステムが最適でないクエリを実行する場合、システムは適切にスケーリングされません。Microsoft の担当者は aspnet メンバーシップデータベースで一般的に良い仕事をしており、userId を int に変更するよりも多くの生産的なことに集中する必要があります。

score 2 · Accepted Answer

通常は int の自動インクリメント番号を使用します。

キーのサイズをできるだけ小さくしたい。これにより、インデックスが小さく保たれ、外部キーにもメリットがあります。さらに、データ設計を外部ユーザーデータに密結合していません (これは aspnet GUID にも当てはまります)。

通常、GUID は大きく、最後のデータページではなく、テーブル内の任意のデータページで挿入が発生する可能性があるため、適切な主キーにはなりません。これに対する主な例外は、複数の複製データベースを実行している場合です。このシナリオでは、GUID はキーに非常に役立ちますが、データベースが 1 つしかないと推測しているので、これは問題ではありません。

score 1 · Accepted Answer

開発に LinqToSql を使用する場合は、主キーとして Int を使用することをお勧めします。nvarchar(x) フィールドに一意のフィールドにするための制約があったとしても、Int 以外のフィールドからリレーションシップを構築したときに、多くの問題が発生しました。

これが LinqToSql の既知のバグなのかどうかはわかりませんが、現在のプロジェクトで問題が発生したため、いくつかのテーブルで PK と FK を交換する必要がありました。

score 0 · Accepted Answer

マイク・ストーンに同意します。また、膨大な量のデータを追跡する場合は、GUIDのみを使用することをお勧めします。それ以外の場合は、単純な自動インクリメント整数（Id）列で十分です。

GUIDが必要な場合、.NETは非常に便利なので、簡単にGUIDを取得できます...

Dim guidProduct As Guid = Guid.NewGuid()

また

Guid guidProduct = Guid.NewGuid();

score 0 · Accepted Answer

私もマイク・ストーンに同意します。私の会社は最近、(LDAP を介して認証する内部ユーザーとは対照的に) 外部クライアント用の新しいユーザーテーブルを実装しました。外部ユーザーについては、GUID を主キーとして保存し、ユーザー名フィールドに一意の制約を付けてユーザー名を varchar として保存することを選択しました。

また、パスワードフィールドを保存する場合は、パスワードをソルト化されハッシュ化されたバイナリとしてデータベースに保存することを強くお勧めします。これにより、誰かがあなたのデータベースをハッキングしたとしても、顧客のパスワードにアクセスできなくなります。

score 0 · Accepted Answer

コードで GUID を使用し、既に述べたように、メールアドレスをユーザー名として使用します。結局のところ、それはユーザーにとってすでにユニークで記憶に残るものです。たぶん、GUIDを捨てることさえあります（v。議論の余地があります）。

これがコードで使用されている場合、GUID でクラスター化インデックスを使用することについて誰かが言及しました。特にINSERTが高い場合は、これを避けます。レコードを INSERT するたびにインデックスが再構築されます。ただし、新しいレコードが追加されるだけなので、クラスター化されたインデックスは自動インクリメント ID でうまく機能します。

asp.net - ASP.NET で認証されたユーザーを参照するには、ユーザー名またはユーザーの ID を使用する必要がありますか?

12 に答える 12

Related

Reference