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

StackOverflow https://stackoverflow.com/questions/4911

  •  08-06-2019
  •  | 
  •  

質問

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

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

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

ご注意ください：

  • .NET で GUID を取得する方法について質問しているわけではありません。単に、.NET の userID 列を参照しているだけです。 asp_ tables ガイドとして。
  • ユーザー名は ASP.NET 認証では一意です。
役に立ちましたか？

解決

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

  1. 主キーはクラスター化インデックスになるため、ユーザー名を使用したユーザーの詳細の検索は非常に高速になります。
  2. 重複したユーザー名が表示されなくなります
  3. 2 つの異なる情報 (ユーザー名または GUID) を使用することを心配する必要はありません。
  4. 2 ビットの情報を検索する必要がなくなるため、コードの記述がはるかに簡単になります。

他のヒント

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

この大きな利点は、すべてのコードがユーザー ID に対して機能するが、ユーザーの名前は実際にはユーザー ID に関連付けられていないことです。その後、ユーザーは自分の名前を変更できます (これはサイト上で便利だと思います)。これは、ユーザーのログインとして電子メール アドレスを使用する場合に特に便利です。これはユーザーにとって非常に便利です (共通のユーザー ID が人気の場合に備えて、20 個の ID を覚える必要がなくなります)。

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

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

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

私はパームジーに同意しますが、彼のコードに少しエラーがあるようです：

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

あるべきです

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

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

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

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

これは古いものですが、これを見つけた人にはいくつかの点に注意していただきたいと思います。

  1. aspnet メンバーシップ データベースは、ユーザー レコードへのアクセスに関して最適化されています。SQL サーバーのクラスター化インデックス シーク (最適) は、Loweredusername と applicationid を使用してレコードが検索されるときに使用されます。ユーザーが最初に資格情報を送信するときにのみ、指定されたユーザー名を使用できるため、これは非常に理にかなっています。

  2. guid userid は int よりも大きなインデックス サイズを与えますが、一度に 1 レコード (ユーザー) しか取得しないことが多く、断片化の観点からは読み取り数が書き込みと編集の数を大幅に上回ることが多いため、これはそれほど重要ではありません。ユーザー テーブルに追加する - 人々はその情報をそれほど頻繁に更新しないだけです。

  3. aspnet メンバーシップ テーブルを作成する regsql スクリプトは、ユーザー ID のデフォルトとして NEWID を使用する代わりに、パフォーマンスが向上する NEWSEQUENTIALID() を使用できるように編集できます (これをプロファイリングしました)。

  4. プロフィール。「新しい学習 Web サイト」を作成する人は、車輪の再発明を試みるべきではありません。私が働いていた Web サイトの 1 つは、(ひどいプロファイル システムを除く) aspnet メンバーシップ テーブルのそのままのバージョンを使用しており、ユーザー テーブルには 200 万近くのユーザー レコードが含まれていました。これほど多くのレコードがあっても、選択は依然として高速でした。なぜなら、最初に述べたように、データベース インデックスは、これらのレコードに対してクラスター化インデックス シークを実行するために、ユーザー名とアプリケーション ID を低く設定することに重点を置いているためです。また、一般的に言えば、SQL がクラスター化インデックス シークを実行している場合は、 1 つのレコードを検索する場合、テーブルに列を追加したり、大量のデータを取得し始めたりしない限り、膨大な数のレコードがあっても問題はありません。

  5. システムの実際のパフォーマンスと経験に基づいて、このシステムの guid について心配することは、時期尚早の最適化であると私は考えます。ユーザー ID に int があるにもかかわらず、カスタム インデックス設計などの理由でシステムが次善のクエリを実行する場合。システムはうまく拡張できません。Microsoft の担当者は、aspnet メンバーシップ データベースに関して概して良い仕事をしました。userId を int に変更するよりも、もっと生産的なことに重点を置くべきことがたくさんあります。

通常は自動増加する数値を int として使用します。

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

一般に、GUID はサイズが大きく、最後のデータ ページではなくテーブル内の任意のデータ ページで挿入が発生する可能性があるため、適切な主キーを作成しません。主な例外は、複数のレプリケートされたデータベースを実行している場合です。このシナリオでは GUID はキーとして非常に役立ちますが、データベースが 1 つしかないため、これは問題ではないと思います。

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

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

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

GUID が必要な場合、.NET は非常に優れており、簡単な操作で GUID を取得できます。

Dim guidProduct As Guid = Guid.NewGuid()

または

Guid guidProduct = Guid.NewGuid();

私もマイク・ストーンの意見に同意します。私の会社は最近、(LDAP 経由で認証する内部ユーザーではなく) 外部クライアント用に新しいユーザー テーブルを実装しました。外部ユーザーの場合は、GUID を主キーとして保存し、ユーザー名フィールドに一意の制約を備えた varchar としてユーザー名を保存することを選択しました。

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

コードでは guid を使用し、すでに述べたように電子メール アドレスをユーザー名として使用します。結局のところ、それはすでにユーザーにとってユニークで記憶に残るものになっています。もしかしたら、GUI を廃止することさえあるかもしれません (v.議論の余地あり）。

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top