ASPNET 멤버십 제공 업체 테이블과 사용자 정의 멤버십 테이블 간의 관계

Question

나는 얼마 전에 사용자 정의 프로필 공급자 예제를 살펴 보았고 이제 그것을 다시 방문하고 있습니다.

내 데이터베이스에는 ASPNET 등록 마법사를 실행할 때 생성 된 모든 DBO.aspNet_* 테이블이 있습니다. 이 테이블에는 aspnet_users를 가리키는 FK 제약 조건이있는 aspnet_profile이 있습니다.

MyDB에는 두 개의 테이블이 있습니다 : 첫 번째, DBO.profiledata에는 DBO.profile을 가리키는 외국의 주요 제약 조건이 있습니다.

내가 이해하고 싶은 것은 MyDB의 테이블이 dbo.aspnet_*의 테이블과 어떻게 관련되는지입니다. MyDB의 프로파일 테이블과 ASPNET 테이블 사이에 외래 키 제약 (또는 어떤 종류의 관계)가 없어야합니까? 내 맞춤형 테이블에 대한 논의는 Aspnet이 제공 한 것과 어떻게 관련이 있는지에 대한 논의는 훌륭 할 것입니다.

미리 감사드립니다.

Answer 1

내가 볼 수있는 두 가지 옵션이 있습니다. 둘 다 기본적으로 동일한 결과를 산출합니다.

• FK dbo.aspnet_User.UserID 에게 dbo.Profile.UserID, 그런 다음 고유 한 키를 정의하십시오 dbo.Profile.UserID (PK 열로 사용하지 않는 한 dbo.Profile)

• FK dbo.aspnet_Profile.ProfileID 에게 dbo.Profile.ProfileID

dbo.aspnet_User 논리적으로 1-1입니다 dbo.aspnet_Profile, 따라서 여전히 동일한 관계 무결성을 얻을 수 있으므로 어떤 접근법을 사용하는지는 중요하지 않습니다.

표준 프로필 데이터 테이블을 자신의 구현으로 교체하는 경우 첫 번째 제안을 사용하는 것이 더 합리적입니다. 그렇지 않으면 프로파일 스키마를 확장하는 경우 두 번째 제안을 사용하십시오.

편집하다

aspnet_Profile 표준 테이블 - 표준입니다 SqlProfileProvider 사용자의 프로필 데이터를 직렬화 된 속성 가방으로 저장합니다. aspnet_Profile, 따라서 왜 별도가 없는가 aspnet_ProfileData 테이블도.

이 접근법을 사용하면 기본 데이터베이스를 변경할 필요없이 프로파일 스키마를 다른 애플리케이션에 대해 쉽게 사용자 정의 할 수 있으며 .NET과 같은 프레임 워크를위한 가장 최적의 솔루션입니다. 단점은 SQL Server 가이 데이터에 쉽게 액세스 할 수 없으므로 T-SQL 및 Set 기반 로직을 사용하여 사용자의 프로필 데이터를 색인, 업데이트 및 쿼리하기가 훨씬 어렵다는 것입니다.

이 제한을 제거하기 위해 본 가장 일반적인 접근법은 표준을 확장하는 것입니다. SqlProfileProvider 응용 프로그램 별 프로파일 속성에 대한 특정 열이있는 사용자 정의 프로필 데이터 테이블에 작성합니다. 이 테이블은 당연히 ASPNET_Profile 테이블과 1-1 관계를 맺고 있으므로 위에 표시된 것처럼 외국 키가 있습니다.

확장 된 제공자의 역할은 프로파일 쓰기 동안 열로 특정 프로파일 속성을 홍보하고 프로파일이 검색 될 때 열에서 읽는 것입니다.

이를 통해 확장 된 제공 업체가 주어진 속성에 대해 '알지 못하는'표준 구현으로 돌아가는 방법을 알고있는 한, 필요한 기준으로 스토리지 솔루션을 혼합 할 수 있습니다.

나는 항상 표준 멤버십 테이블을 그대로두고 적절한 외국 키가있는 새 테이블을 사용하여 필요한 곳을 확장 한 다음 적절한 공급자를 서브 클래스하고 자신의 구현으로 제공자 메소드를 재정의하는 것이 가장 좋습니다 (가능한 한 기본 구현으로 호출하십시오. ).