이메일 주소를 기본 키로 사용 하시겠습니까?

자동 증가 숫자와 비교할 때 이메일 주소가 기본에 적합하지 않습니까?

우리 웹 애플리케이션은 시스템에서 이메일 주소가 고유해야합니다. 그래서 이메일 주소를 기본 키로 사용하려고 생각했습니다. 그러나 제 동료는 문자열 비교가 정수 비교보다 느릴 것이라고 제안합니다.

이메일을 기본 키로 사용하지 않는 것이 합당한 이유입니까?

우리는를 사용하고 PostgreSQL있습니다.

문자열 비교는 int 비교보다 느립니다. 그러나 전자 메일 주소를 사용하여 데이터베이스에서 사용자를 검색하는 경우에는 문제가되지 않습니다. 조인이 여러 개인 복잡한 쿼리가 있는지 여부는 중요합니다.

여러 테이블에 사용자에 대한 정보를 저장하면 users 테이블의 외래 키가 전자 메일 주소가됩니다. 즉, 전자 메일 주소를 여러 번 저장합니다.

또한 이메일은 고유 한 분야를 만들기에는 나쁜 선택이며 이메일 주소를 공유하는 사람과 소규모 기업도 있습니다. 전화 번호와 마찬가지로 이메일도 재사용 할 수 있습니다. Jsmith@somecompany.com은 1 년 후 John Smith와 2 년 후 Julia Smith에 쉽게 속할 수 있습니다.

이메일의 또 다른 문제점은 이메일이 자주 변경된다는 것입니다. 키를 사용하여 다른 테이블에 조인하는 경우 전체 클라이언트 회사가 전자 메일을 변경하면 다른 성능을 발휘할 수있는 다른 테이블도 업데이트해야합니다.

기본 키는 고유 하고 일정 해야합니다.

이메일 주소는 계절에 따라 변경됩니다. 조회에는 보조 키로 유용하지만 기본 키에는 적합하지 않습니다.

이메일 주소를 기본 키로 사용하는 단점 :

1. 조인을 수행 할 때 속도가 느려집니다.

2. 게시 된 외래 키가있는 다른 레코드는 더 큰 값을 가지므로 더 많은 디스크 공간을 차지합니다. (오늘 디스크 공간 비용을 감안하면 레코드를 읽는 데 시간이 오래 걸리는 경우를 제외하고는 사소한 문제 일 수 있습니다. # 1 참조)

3. 이메일 주소가 변경 될 수 있으며,이를 외래 키로 사용하는 모든 레코드가 업데이트됩니다. 이메일 주소는 자주 변경되지 않으므로 성능 문제는 미미합니다. 더 큰 문제는 반드시 제공해야한다는 것입니다. 코드를 작성해야하는 경우, 이것은 더 많은 작업이며 버그의 가능성을 소개합니다. 데이터베이스 엔진이 "업데이트 캐스케이드"를 지원하는 경우 사소한 문제입니다.

이메일 주소를 기본 키로 사용하는 이점 :

1. 일부 조인을 완전히 제거 할 수 있습니다. "마스터 레코드"에서 필요한 모든 이메일 주소 인 경우 추상 정수 키를 사용하여 검색하려면 조인을 수행해야합니다. 키가 이메일 주소 인 경우 이미 가지고 있으며 가입 할 필요가 없습니다. 이것이 당신에게 도움이되는지 여부는이 상황이 얼마나 자주 발생하는지에 달려 있습니다.

2. 임시 쿼리를 수행 할 때 사람은 어떤 마스터 레코드가 참조되는지 쉽게 알 수 있습니다. 데이터 문제를 추적 할 때 큰 도움이 될 수 있습니다.

3. 어쨌든 거의 확실하게 전자 메일 주소에 대한 색인이 필요하므로 기본 키로 만들면 하나의 색인이 제거되므로 이제 삽입 할 색인이 하나만 있으므로 삽입 성능이 향상됩니다.

겸손한 의견으로는 슬램 덩크가 아닙니다. 실제 키를 사용할 수있을 때 자연 키를 사용하는 것이 더 쉬워서 사용하는 편이 좋으며 단점은 대부분의 경우 실제로 중요하지 않습니다.

꽤 나쁘다. 일부 전자 메일 공급자가 업무를 중단했다고 가정합니다. 그런 다음 사용자는 전자 메일을 변경하려고합니다. 전자 메일을 기본 키로 사용한 경우 사용자의 모든 외래 키는 해당 전자 메일을 복제하여 변경하기가 어렵습니다 ...

... 그리고 성능 고려 사항에 대해서도 이야기하지 않았습니다.

이것이 설정에 문제가 될 수 있는지는 모르겠지만 RDBMS에 따라 열의 값은 대소 문자를 구분할 수 있습니다 . PostgreSQL 문서는 "열을 UNIQUE 또는 PRIMARY KEY로 선언하면 암시 적으로 생성 된 인덱스는 대소 문자를 구분합니다"라고 말합니다. 즉, 이메일을 기본 키로 사용하여 테이블에서 검색을위한 사용자 입력을 허용하고 사용자가 "John@Doe.com"을 제공하면 "john@doe.com"을 찾을 수 없습니다.

전자 메일 주소가 개인 정보로 간주 될 수있는 가능한 문제에 대해 언급 한 사람은 없습니다. 이메일 주소가 기본 키인 경우 프로필 페이지 URL은 다음과 같습니다 ..../Users/my@email.com. 사용자의 이메일 주소를 공개하지 않으려면 어떻게해야합니까? URL을 만들려면 고유 한 정수 값으로 사용자를 식별하는 다른 방법을 찾아야합니다 ..../Users/1. 그런 다음 결국 고유 한 정수 값으로 끝납니다.

상기 논리적 수준 , 이메일은 자연의 열쇠입니다. 상기 물리적 수준, 관계형 데이터베이스를 사용하는 주어진 자연 키는 기본 키로 잘 맞지 않습니다. 그 이유는 주로 다른 사람들이 언급 한 성능 문제 때문입니다.

이러한 이유로 디자인을 조정할 수 있습니다. 자연 키는 대체 키 (UNIQUE, NOT NULL)가되며, 대리 / 인공 / 기술 키 를 기본 키로 사용하며,이 경우 자동 증분이 될 수 있습니다.

systempuntoout가 물었다.

누군가 이메일 주소를 변경하려면 어떻게해야합니까? 외래 키도 모두 변경 하시겠습니까?

그것이 계단식 입니다.

숫자 대체 키를 기본 키로 사용하는 또 다른 이유는 플랫폼에서 인덱싱이 작동하는 방식과 관련이 있습니다. 예를 들어 MySQL의 InnoDB에서 테이블의 모든 인덱스에는 기본 키가 미리 추가되어 있으므로 PK를 가능한 한 작게 (속도와 크기를 위해) 원합니다. 이와 관련하여 InnoDB는 기본 키가 순서대로 저장 될 때 더 빠르며 문자열이 도움이되지 않습니다.

문자열을 대체 키로 사용할 때 고려해야 할 또 다른 사항은 원하는 실제 문자열의 해시를 사용하면 더 빠를 수 있으며 일부 문자의 대소 문자를 건너 뛸 수 있다는 것입니다. (방금 말한 것을 확인하기 위해 참조를 찾는 동안 실제로 여기에 도착했습니다.

예, 사용자가 이메일 주소를 업데이트하려고하기 때문에 잘못된 기본 키입니다.

예, 대신 정수를 사용하는 것이 좋습니다. 이메일 열을 고유 제한 조건으로 설정할 수도 있습니다.

이처럼 :

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);

정수 기본 키가 더 좋은 또 다른 이유는 다른 테이블에서 전자 메일 주소를 참조 할 때입니다. 주소 자체가 기본 키인 경우 다른 테이블에서 해당 키를 키로 사용해야합니다. 따라서 이메일 주소를 여러 번 저장합니다.

나는 postgres에 익숙하지 않습니다. 기본 키는 큰 주제입니다. 이 사이트 (stackoverflow.com)에서 훌륭한 질문과 답변을 보았습니다.

숫자 기본 키를 사용하고 전자 메일 열에 UNIQUE INDEX를 사용하면 성능이 향상 될 수 있다고 생각합니다. 이메일의 길이는 다양하며 기본 키 색인에 적합하지 않을 수 있습니다.

여기 와 여기에 약간의 독서 .

개인적으로 데이터베이스를 설계 할 때 기본 키에 대한 정보를 사용하지 않습니다. 나중에 정보를 변경해야 할 가능성이 높기 때문입니다. 기본 키를 제공하는 유일한 이유는 클라이언트 측에서 대부분의 SQL 작업을 수행하는 것이 편리하고 그에 대한 나의 선택은 항상 자동 증가 정수 유형이었습니다.

동료가 맞습니다. 기본 키에 자동 증가 정수를 사용하십시오.

응용 프로그램 수준에서 전자 메일 고유성을 구현하거나 전자 메일 주소 열을 고유 한 것으로 표시하고 해당 열에 색인을 추가 할 수 있습니다.

필드를 고유 한 이름으로 추가하면 조인 및 외래 키 제약 조건 검사를 수행 할 때가 아니라 해당 테이블에 삽입 할 때만 문자열 비교가 필요합니다.

물론 데이터베이스 수준에서 응용 프로그램에 제약 조건을 추가하면 앱이 융통성이 없어 질 수 있습니다. 응용 프로그램이 고유하거나 비어 있지 않아야하기 때문에 필드를 "고유"또는 "널이 아님"으로 만들기 전에 항상 적절한 고려를하십시오.

GUID를 기본 키로 사용하십시오. INSERT를 수행 할 때 프로그램에서 GUID를 생성 할 수 있으며 기본 키가 무엇인지 찾기 위해 서버에서 응답을받을 필요가 없습니다. 또한 고유 한 전체 테이블과 데이터베이스가 될 것이며 언젠가 테이블을 자르고 자동 증분이 1로 재설정되면 어떻게 될지 걱정할 필요가 없습니다.

나는 이것이 약간의 늦은 항목이라는 것을 알고 있지만 사람들이 이메일 계정을 포기하고 서비스 제공 업체가 다른 사람이 사용할 수 있도록 주소를 복구한다고 덧붙이고 싶습니다.

@HLGEM이 지적했듯이 "Jsmith@somecompany.com은 1 년 후 John Smith와 2 년 후 Julia Smith에 쉽게 속할 수 있습니다." 이 경우 John Smith가 서비스를 원할 경우 그의 이메일 주소 사용을 거부하거나 Julia Smith와 관련된 모든 기록을 삭제해야합니다.

현지 법에 따라 기록을 삭제해야하고 사업의 재무 이력과 관련이있는 경우 뜨거운 물에서 자신을 찾을 수 있습니다.

따라서 이메일 주소, 번호판 등과 같은 데이터를 기본 키로 사용하지는 않을 것입니다.이 키는 고유하지 않더라도 처리 할 수없는 몇 가지 흥미로운 과제를 제공 할 수 있기 때문입니다.

적용 가능한 데이터 규제 법률을 고려해야 할 수도 있습니다. 이메일은 개인 정보이며, 사용자가 예를 들어 GDPR에 따라 EU 시민 인 경우 기록에서 정보를 삭제하도록 지시 할 수 있습니다 (귀하가 거주하는 국가에 관계없이 적용됨).

참조 무결성이나 감사와 같은 기록적인 이유로 레코드 자체를 데이터베이스에 보관해야하는 경우 대리 키를 사용하면 모든 개인 데이터 필드를 NULL로 지정할 수 있습니다. 개인 데이터가 기본 키라면 쉽지 않습니다.

정수 기본 키를 사용하여 성능을 향상시킬 수 있습니다.

정수 기본 키를 사용해야합니다. 전자 메일 열이 고유해야하는 경우 해당 열에 고유 색인을 설정하지 않는 이유는 무엇입니까?

기본 키로 int 값이 아닌 값을 사용하면 큰 데이터에서 삽입 및 검색 속도가 매우 느려집니다.

기본 키는 정적 속성으로 선택해야합니다. 이메일 주소는 고정적이지 않으며 여러 후보가 공유 할 수 있으므로 기본 키로 사용하는 것은 좋지 않습니다. 또한 이메일 주소는 일반적으로 특정 길이의 문자열이며 [len (email_address)> len (unique_id)]를 사용하려는 고유 ID보다 클 수 있으므로 더 많은 공간이 필요하며 최악의 경우 외래 키로 여러 번 저장됩니다 . 결과적으로 성능이 저하됩니다.

테이블에 따라 다릅니다. 표의 행이 이메일 주소를 나타내는 경우 이메일이 가장 좋은 ID입니다. 그렇지 않은 경우 이메일은 좋은 ID가 아닙니다.

이메일이 고유해야하는 문제 일 경우 해당 열을 사용하여 고유 한 인덱스를 만들면됩니다.

이메일은 고유 한 인덱스 후보이지만 기본 키에는 적합하지 않습니다. 기본 키인 경우 연락처의 이메일 주소를 변경할 수 없습니다. 조인 쿼리도 느려질 것이라고 생각합니다.

이메일 주소를 기본 키로 사용하지 말고 이메일을 고유하게 유지하지만 기본 키로 사용하지 말고 사용자 ID 또는 사용자 이름을 기본 키로 사용하십시오.