이메일 주소 고유 또는 기본 키?

나는 데이터베이스의 초보자입니다. 문자열을 비교하면 속도가 느려 복잡한 조인의 성능에 영향을 미치며 전자 메일이 변경되면 많은 외래 키를 변경해야하기 때문에 전자 메일 주소를 기본 키로 사용하는 것이 좋지 않다는 것을 알았습니다. 노력의.

그러나 내 users 테이블에 모든 사용자에게 전자 메일 주소가 있어야하고 각 전자 메일 주소가 고유해야하는 경우 전자 메일 열에 고유 인덱스를 추가하면 충분합니까? afaik 고유 필드는 null 값을 허용하지만 모든 사용자에게는 null 값을 허용하지 않는 전자 메일 주소가 있어야합니다. 내가 여기서 놓친 것이 있습니까? 또는 전자 메일 열을 고유하게 만들고 서버에서 데이터를 확인하는 동안 모든 사용자가 전자 메일 주소를 갖도록 사용자가 전자 메일 주소를 입력했는지 확인하고 싶습니다.

postgresql primary-key unique-constraint

— aandis
소스

사용자가 자신의 이메일 주소를 변경하면 어떻게됩니까? 예 : 작업 변경

— user151019

문자열 비교는 속도가 느릴뿐만 아니라 문자열도 정수보다 큰 경향이 있으므로 메모리의 페이지에 더 적게 맞을 수 있으므로 쿼리에 대한 논리적 읽기가 증가합니다.

— 이름이없는 1

답변:

키와 인덱스를 먼저 구분 해 봅시다. 키는 논리 모델의 일부이며 종종 고유 인덱스로 구현됩니다. 그러나 키를 만들지 않고 고유 인덱스를 만들 수 있지만 외래 키로 참조 할 수는 없습니다.

후보 키는 테이블에서 행을 고유하게 식별하는 것입니다. SQL에서 후보 키 중 하나는 일반적으로 기본 키로 사용됩니다 (ck 중 하나가 다른 것보다 "더 나은"이유를 실제로 이해하지는 못했지만 다른 것은 아닙니다. 이야기), 나머지 ck는 독특한 제약이됩니다.

고유 키 제약 조건은 기본 키와 동일한 방식으로 사용할 수 있습니다. 치다:

create table A ( x ... not null
               , y ... not null
               , z ... not null
               ,     unique (x)
               ,     primary key (y,z) );

create table B ( x ...
               ,   ...
               ,     foreign key (x) references A (x) );

create table C ( y ...
               , z ...
               ,   ...
               ,     foreign key (y, z) references A (y, z) );

B는 고유 제한 조건을 참조하고 C는 기본 키 제한 조건을 참조합니다.

NOT NULL은 또 다른 종류의 제약입니다. 귀하의 경우 이메일을 고유하게 선언하지 않고 이메일에 적용 할 수 있습니다.

게시물의 다음 측면은 키의 안정성과 관련이 있습니다. 키는 안정적이어야합니다 (그러나 절대 변경할 수는 없으며 변경할 수는 없습니다). 일부 DBMS는 ON UPDATE CASCADE를 구현하여 이러한 작업에 도움이 될 수 있지만 모델에 키가 분산되어 있으면 업데이트가 어려울 수 있습니다.

귀하의 경우 다른 후보 키를 기본 키로 선택하고 이메일을 NOT NULL 및 UNIQUE로 선언합니다.

— 레나르트
소스

SQL Server에서는 고유 인덱스를 FK로 참조 할 수 있습니다.

— Martin Smith

SQL에 액세스 할 수 없으므로 직접 확인할 수 없습니다. 고유 인덱스를 만들 때 암시 적으로 고유 제약 조건이 생성됩니까?

— Lennart

아니요. 고유 제약 조건은 약간 다르게 처리되며 고유 인덱스에 비해 추가 메타 데이터와 추가 제한이 있지만 SQL Server에서는 FK에서 둘 중 하나를 사용할 수 있습니다.

— Martin Smith

그것은 조금 이상합니다. 키는 SQL 표준에서 언급되지 않았지만 키는 그것의 중심 부분입니다. 어쨌든 정보 감사합니다.

— Lennart

이메일에 외래 키가 많은 레코드가 많은 경우 업데이트가 진행될 때 모든 레코드를 업데이트하는 데 상당한 시간이 걸릴 수 있습니다.

— cimmanon

예, EmailAddress 열에 고유 인덱스가 있으면 괜찮습니다. 유일한 문제는 누군가가 서비스에 가입 한 후 이메일 주소를 포기했지만 알려주지 않은 경우 이메일 주소 소유자가 가입을 시도하는 것입니다. 그러나 이것은 매우 드문 경우입니다.

고유 색인이 데이터베이스 플랫폼에 따라 널 (NULL) 값을 허용하는지와 관련하여. Oracle은 SQL Server에서 단일 NULL 값을 허용합니다. 열에 NULL 값을 허용하지 않도록 한 다음 고유 인덱스를 작성하여이 문제를 해결할 수 있습니다.

— mrdenny
소스

SQL 서버에 대해서는 사실이 아닙니다. where예를 들어 NULL인덱스에서 값 을 제외 할 수 있는 절을 사용하여 인덱스를 만들 수 있습니다 .

— Kirk Woll

그 진술 SQL Server allows a single NULL value은 여전히 사실입니다. 여러 NULL값 을 얻을 수있는 방법이 없다고 말하는 것은 아닙니다 . 답변자는 간단한 답변을 유지하려고 노력했지만 추가 세부 사항 (예 : 필터링 된 색인화)을 설명하지 않으려 고 생각했습니다.

— Brandon

그렇습니다. 토끼 전체에 필터링 된 인덱스를 모두 줄 였을 수 있지만 간단한 질문에는 대개 간단한 대답이 필요합니다. 데이터베이스 플랫폼과 버전이 없으면 답변을 일반적으로 유지합니다.

— mrdenny

EmailAddress에 고유 인덱스가 있으면 좋습니다.

응용 프로그램에서 전자 메일 주소를 필수 필드로 사용하는 것에 대한 유효성 검사가 이미 언급되었으므로 데이터베이스의 다른 유효성 검사는 전자 메일 주소가없는 사용자를 수락하지 않으며 중복 항목도 방지하는 것입니다. 이 고유 색인으로 부과됩니다.

SQL Server에 대한 다른 답변에서 언급했듯이 고유 인덱스를 작성하기 전에 열에 null 값을 허용하지 않아야합니다.

— 비 제프
소스