사용자 이름이나 사용자 ID를 사용하여 ASP.NET에서 인증 된 사용자를 참조해야합니까?

Question

간단한 학습 웹 사이트에서 기본 ASP.NET 인증 시스템을 사용합니다.

나는 그의 우편과 같은 물건을 저장 이제 사용자 테이블을 추가하고, DOB는 내 질문은 등 :

새 테이블에서

1. 는, 키가 사용자 이름 (문자열) 또는 사용자 여야합니다 ID는 asp_ tables에서 사용하는 해당 GUID 찾기 번호입니다.
2. 모범 사례가 그 추한 guid를 사용하는 경우, 그것을 얻는 방법을 아는 사람이 있습니까? 그것은 쉽게 액세스 할 수없는 것 같습니다 (System.Web.HttpContext.Current.User.Identity.Name)
3. 당신은 (안돼 guid 또는 ASP.NET 인증에 의해 제공되는 userName 필드가 아닌) 사용하는 것이 좋습니다 경우 ASP.NET 인증을 어떻게합니까? 내가 좋아하는 한 가지 옵션은 사용자의 전자 메일 주소를 로그인으로 사용하는 것이지만 ASP.NET 인증 시스템에서 사용자 이름 대신 전자 메일 주소를 사용하는 방법은 무엇입니까? (또는 제가 사용자 이름이 실제로 이메일 주소입니다 "알고있다"결정 그냥, 거기에 아무 상관이없는

참고 :?

• 을 나는 GUID에서 얻을 방법에 대한 요구 하진 않았어 .NET, 난 그냥
이

Answer 1

나는 이름이 고유 될 것입니다 경우 테이블의 기본 키로 이름을 사용하는 것이 좋습니다 것,이 할 수있는 몇 가지 좋은 이유가 있습니다 :

가

1. 기본 키가 될 것이다 클러스터 된 색인 및 사용자 이름을 통한 사용자 세부 정보 검색이 매우 빠릅니다.
2. 그것은
3. 나타나는 중복 사용자 이름을 중지 당신은 그것을 때문에 두 비트를 조회하지 않아도의 코드를 작성 훨씬 쉽게 만들 것입니다 정보의 서로 다른 두 가지 peices (사용자 이름 또는 GUID)
4. 를 사용하는 방법에 대해 걱정할 필요가 없습니다 정보.

Answer 2

당신은 몇 가지 고유 한 ID를 사용해야합니다.

사용자 이름은 ASP.NET 인증에 고유합니다. GUID로 asp_ tables의 사용자 ID 열을 참조 중 하나 GUID하고 당신이 언급 또는 일부 다른 자동 생성기 ated 키. 그러나이 번호는 사용자가 볼 수 없습니다.

큰 이점은 모든 코드가 사용자 ID에서 작동 할 수 있지만 사용자 이름이 실제로 그 코드에 묶여 있지 않다는 것입니다. 그런 다음 사용자는 사이트에서 유용하다고 생각한 이름을 변경할 수 있습니다. 이것은 사용자의 로그인으로 전자 메일 주소를 사용하는 경우 특히 유용합니다 ... 사용자에게 매우 편리합니다 (공통 사용자 ID가 널리 사용되는 경우 20 개의 ID를 기억할 필요가 없습니다).

Answer 3

나는 Mike Stone과 동의한다. 방대한 양의 데이터를 추적하려는 경우에만 GUID 만 사용하는 것이 좋습니다. 그렇지 않으면 간단한 자동 증가 정수 (Id) 열이면 충분합니다. 당신은 GUID를 필요로 할 경우, .NET은 간단한 하나를 얻을 수있을만큼 사랑스러운

...

Dim guidProduct As Guid = Guid.NewGuid() 

또는

Guid guidProduct = Guid.NewGuid(); 

Answer 4

당신은 사용자 ID를 사용해야합니다. MembershipUser의 ProviderUserKey 속성입니다.

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

Answer 5

사용자 ID를 사용합니다. 사용자 이름을 사용하려면 "사용자 이름 변경"기능을 매우 비쌉니다.

Answer 6

개발을 위해 LinqToSql을 사용하려는 경우 Int를 기본 키로 사용하는 것이 좋습니다. 나는 nvarchar (x) 필드에 고유 한 필드로 만드는 제약 조건이 있더라도 비 Int 필드로 구축 된 관계가있을 때 많은 문제가있었습니다.

이것이 LinqToSql의 알려진 버그인지, 아니면 현재 프로젝트에서 문제가 있었는지 확실하지 않아 여러 테이블에서 PK와 FK를 교환해야했습니다.

Answer 7

나는 마이크 스톤 (Mike Stone)에게도 동의하고 있습니다. 우리 회사는 최근 LDAP를 통해 인증하는 내부 사용자가 아닌 외부 사용자를 위해 새로운 사용자 테이블을 구현했습니다. 외부 사용자의 경우 GUID를 기본 키로 저장하고 사용자 이름 필드에 고유 한 제약 조건이있는 varchar로 사용자 이름을 저장하기로했습니다.

또한 암호 필드를 저장하려는 경우 암호를 데이터베이스에 해시 된 해시 된 바이너리로 저장하는 것이 좋습니다. 이렇게하면 누군가 데이터베이스를 해킹하면 고객의 암호에 액세스 할 수 없게됩니다.

Answer 8

보통 자동 증가 숫자 인 int를 사용합니다.

키의 크기를 가능한 작게 유지하려고합니다. 이렇게하면 색인을 작게 유지하고 모든 외래 키에도 도움이됩니다. Additonally 당신은 단단히 외부 사용자 데이터 (이것은 aspnet GUID도 마찬가지입니다)에 데이터 디자인을 결합하지 않습니다.

일반적으로 GUID는 큰 기본 키를 만들지 않으며 삽입은 마지막 데이터 페이지가 아닌 테이블 내의 잠재적으로 모든 데이터 페이지에서 발생할 수 있습니다. 이것에 대한 주요 예외는 mutilple 복제 데이터베이스를 실행하는 경우입니다. GUID는이 시나리오의 키에 매우 유용하지만 문제가되지 않도록 데이터베이스가 하나만 있다고 추측합니다. 사용자 이름은 아직 변경할 수 있도록

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

이

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

Answer 9

나는 Palmsey, 에 동의 기본 키에 영향을 미치지 않습니다. 또한 사용자 이름 열을 고유하게 설정하여 중복 된 사용자 이름을 막을 수 있습니다.

사용자 ID보다는 사용자 이름을 주로 검색한다면 사용자 이름을 클러스터 된 색인으로 만들고 기본 키를 클러스터되지 않도록 설정하십시오. 사용자 이름을 검색 할 때 가장 빠른 액세스를 제공하지만 주로 UserIds를 검색 한 다음 클러스터 된 인덱스로 남겨두면됩니다.

편집 : 이것은 또한 사용자 ID를 기본 키로 사용하므로 현재 ASP.Net 멤버십 테이블과 더 잘 맞을 것입니다.

Answer 10

내가 사용에게 사용자 ID를 말을해야한다 : 자신의 코드에 약간의 오류가있을 것 같습니다 있지만

Answer 11

내 코드에서 guid를 사용하고 이미 사용자 이름으로 이메일 주소를 언급했습니다.그것은 결국, 이미 독특하고 기억에 남을 사용자입니다. 어쩌면 guid (논쟁의 여지가있는)를 버릴 수도 있습니다.

누군가 코드에서 GUID가 클러스터 된 인덱스를 사용했다면 GUID에 언급했습니다. 특히 INSERT가 높으면이 문제를 피할 수 있습니다. 레코드를 INSERT 할 때마다 색인이 다시 작성됩니다. 새 레코드가 추가되기 때문에 클러스터 된 인덱스는 자동 증가 ID에서 제대로 작동합니다.

Answer 12

이 오래지만 난 그냥이 몇 가지주의를 찾을 명 : 원함 사용자 레코드에 액세스하는 때

1. ASPNET 회원 데이터베이스에 최적화되어 있습니다. SQL Server에서 clustered index seek (optimal)은 하위 사용자 이름과 applicationid를 사용하여 레코드를 검색 할 때 사용됩니다. 사용자가 처음으로 자격 증명을 전송할 때 제공되는 사용자 이름 만 가지고 있기 때문에 이것은 많은 의미가 있습니다.

2. guid 사용자 ID는 int보다 큰 색인 크기를 제공하지만 우리는 한 번에 하나의 레코드 (사용자) 만 검색하고 조각화면에서 대개 읽기가 많기 때문에 대개 중요합니다. 사용자 테이블에 대한 쓰기 및 편집 횟수 - 사람들은 그 정보를 자주 업데이트하지 않습니다.

3. aspnet 멤버십 테이블을 만드는 regsql 스크립트를 편집하여 userid의 기본값으로 NEWID를 사용하는 대신 더 나은 성능을 제공하는 NEWSEQUENTIALID()를 사용할 수 있습니다 (프로파일 링했습니다).

4. 프로파일. "새로운 학습 웹 사이트"를 만드는 누군가는 바퀴를 재발 명하려고해서는 안됩니다. 내가 일한 웹 사이트 중 하나는 aspnet 회원 테이블 (끔찍한 프로필 시스템 제외)의 상자 버전을 사용했고 users 테이블에는 거의 2 백만 개의 사용자 레코드가 포함되어있었습니다. 이렇게 많은 수의 레코드가 있더라도 select는 여전히 빠르다. 왜냐하면 내가 말했듯이, 데이터베이스 인덱스는 하위 레코드 이름에 lowerusername + applicationid에 초점을 맞추고 있기 때문에 클러스터 된 인덱스는 이러한 레코드를 찾는다. 일반적으로 sql이 클러스터 된 인덱스 찾기를 수행하는 경우 1 개의 레코드를 찾으려면 테이블에 열을 추가하지 않고 많은 양의 데이터를 가져 오는 것이 아니라면 엄청난 수의 레코드가있는 경우에도 문제가 없습니다.

5. 시스템의 실제 성능과 경험을 바탕으로이 시스템에서 guid를 걱정하는 것은 조숙 한 최적화입니다. 사용자 ID에 int가 있지만 사용자 정의 색인 설계 등으로 인해 시스템이 최적이 아닌 조회를 수행하는 경우 시스템의 확장이 잘되지 않습니다. Microsoft 놈들은 aspnet 멤버십 db로 일반적으로 좋은 일을했고, userId를 int로 바꾸는 것보다 많은 집중적 인 일들이있었습니다.