254 자의 전자 메일 주소는 유효하지만 내가 연구 한 구현은 varchar (60) ~ varchar (80) 또는 이와 동등한 것을 사용하는 경향이 있음을 이해합니다. 예를 들어이 SQL Server 권장 사항 은 varchar (80) 또는 이 Oracle 예를 사용합니다.
최대 254자를 사용하지 않는 이유가 있습니까? varchar는 정의에 따라 데이터를 보유하는 데 필요한만큼의 스토리지 만 사용하지 않습니까?
많은 구현에서 전체 254 자 미만의 문자를 사용하게하는 상당한 성능 영향 / 거래가 있습니까?
답변:
나는 항상 사용했습니다 VARCHAR(320). 이유는 다음과 같습니다. 이 표준 은 다음과 같은 제한 사항을 규정합니다.
@기호 는 1 자입니다 .이제 일부 사람들은 그 이상을 지원해야한다고 말합니다. 일부 사람들은 도메인 이름에 유니 코드를 지원해야한다고 말합니다 (즉,로 전환해야 함 NVARCHAR). 그 동안 표준이 변경 될 수는 있지만 (게임에 스킨을 적용한 지 오래되었습니다), 현재는 세계 대부분의 서버가 유니 코드 전자 메일 주소를 허용하지 않을 것이라고 확신합니다. 많은 서버에서 320 자 이상의 주소를 생성 및 / 또는 수락하는 데 문제가 있습니다.
즉, 원하는 경우 최악의 상황에 대비할 수 있습니다. SQL Server 2008 R2 이상에서 데이터 압축을 사용하는 경우 유니 코드 압축의 이점이 있습니다. 즉, 실제로 필요한 문자에 대해서는 2 바이트의 벌금 만 지불하면됩니다 그것). 이렇게하면 원하는만큼 열을 넓힐 수 있고 사람들이 원하는 곳에 너무 긴 정크를 넣을 수 있습니다. 그들이 원하는 것처럼 정크를 주면 이메일을받지 못합니다. 삽입이 실패하면 이메일을받습니다. 당신이 무효 쓰레기를 할 경우 문제는 당신그것을 처리해야합니다. 크기에 상관없이 누군가 320 자 열에 400자를 채우려 고하면 1025 자 문자를 1024 자 열에 넣으려고합니다. 현명한 사람이 시스템 경계를 명시 적으로 테스트하기 위해 사용하지 않는 전자 메일 주소가 320자를 초과해야하는 이유는 없습니다.
그러나 이것에 대한 의견 을 묻지 말고 지침에 대한 다른 구현을 찾는 것을 중단하십시오 (이 경우 참조 한 사람들이 자신의 숙제를하고 귀찮게하지 않았기 때문에 발생합니다) . 표준에 직접 액세스 할 수 있습니다. 최신 버전을 참조하고 최소한으로 지원 하며 표준의 최신 상태를 유지하여 사양 변경에 적응할 수 있도록하십시오.
편집 덕분에 채팅 핑 (ping)에 대한 @ypercube합니다.
제쳐두고, 아마도 당신은 전체 주소를 처음에 하나의 열에 덤프하고 싶지 않을 것입니다. 정규화 @hotmail.com는 훨씬 더 얇은 FK int가 제대로 작동하고 가변 길이 열의 추가 오버 헤드가 없을 때 1500 만 번 을 저장하고 싶지 않다고 제안 할 수 있습니다. 또한 정상화 사용자 이름은, 같은 수 john.smith@hotmail.com및 john.smith@gmail.com공통 이름을 공유 - 그들은 서로 모르는 그러나 당신의 데이터베이스는 그것에 대해 상관하지 않는다.
나는 이것에 대해 이것에 대해 이야기했다 :
http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/
그러나 유효한 255 자 도메인이 유효한 1 자 로컬 파트와 결합 될 때 발생하는 상황에 대해서는 합의가 보이지 않기 때문에 위의 254 자 제한에 대한 문제가 발생합니다. 이것은 전 세계 대부분의 서버에서 받아 들여야하지만이 254 자 제한을 위반하는 것 같습니다. 따라서 Domains도메인을 유효한 255 자 URL로 재사용 할 수 있을 때 전자 메일 주소 길이에 대해 인위적으로 더 낮은 제한이 있는 테이블을 작성 합니까?
이 결정에는 몇 가지 고려 사항이 있습니다. 가장 중요한 것은 데이터가 준수해야 할 필수 한계에 대한 현재 및 미래 예측을 사용하는 것입니다. 32자를 초과 하지 않아야 varchar(1024)하는 문자열을 저장하는 경우 모든 문자열 열 데이터 유형을 설정하지 않는 이유가 있습니다 ( should 키워드 에 강조 표시 ).
전자 메일이 모두 255 자로 변경되는 취약점이있는 경우 페이지 분할의 성능에 오랜 영향을 줄 수 있습니다. 이것은 평범하지 않은 것처럼 보일 수도 있지만 대부분의 경우 비즈니스 요구 사항에 맞게 데이터 크기 를 조정해야합니다 . 데이터베이스 대 애플리케이션 토론의 오래된 제약과 마찬가지로 데이터 유형 제한과 허용 가능한 값도 데이터 계층에서 시행해야한다고 확신합니다.
다음 단계로 안내합니다. 데이터베이스는 데이터 계층 일 가능성이 높습니다. 응용 프로그램 계층은 무엇을 사용합니까? 예를 들어, 이메일 주소로 80자를 입력 할 수있는 응용 프로그램이있는 경우 왜 데이터 유형을 더 크게 설정 하시겠습니까? 비즈니스는 다음 두 가지 질문에 대답해야합니다.
그래야만 답을 얻을 수 있습니다.
varchar는 정의에 따라 데이터를 보유하는 데 필요한만큼의 스토리지 만 사용하지 않습니까?
예, 아니오 가변 길이 데이터의 길이를 기록하기위한 일종의 오프셋이 있습니다.
RFC 5321 (현재 SMTP 사양, RFC2821 사용되지 않음) 상태는 다음과 같습니다.
사용자 이름 또는 다른 로컬 부분의 최대 총 길이는 64 옥텟입니다. 도메인 이름 또는 숫자의 최대 총 길이는 255 옥텟입니다.
따라서 64 + 255 + @ 기호는 VARCHAR (320)을 의미합니다. 당신은 아마 이것을 많이 필요로하지 않을 것입니다.
VARCHAR의 변형은 데이터 블록에서 필요한만큼의 공간 만 사용합니다. 길이를 저장하기위한 추가 바이트는 고정 길이 CHAR을 대신 사용하여 낭비되는 공간과 비교하여 사소한 것입니다.
VARCHAR 열 길이는 실제로 "최대 길이"이므로 모든 상황에서 가능한 최대 길이보다 크게 설정해야합니다. 각 행에 필요한만큼의 공간 만 사용됩니다. 그런 다음 응용 프로그램은 스크롤 필드 또는 일반적인 값을 기반으로하는 것이 무엇이든 설계해야합니다.
데이터베이스 디자인은 크기에 대한 제한을 설정한다는 점에서 실제 종이와 같습니다. 용지 페이지를 확대 할 수 없습니다. 이 비유에서 응용 프로그램은 페이지에 인쇄 된 양식과 같습니다. 양식에 보유 할 수있는 데이터 양을 조정하기 위해 수행 할 수있는 작업이 많이 있습니다.
VARCHAR 크기를 늘리는 명령이 단순 해 보이고 작은 테이블에서 즉시 실행될 수 있지만, 수천 개 이상의 행이있는 테이블에서이를 수행하려면 모든 데이터 및 인덱스 블록을 재생성하는 동안 일종의 데이터베이스 Quiesce가 필요할 수 있습니다. 한 가지 방법은 열이 큰 새 테이블에 모든 것을 복사하는 것입니다. 어떤 기술을 사용하든간에 그것은 대단한 거래입니다. 따라서, 프로덕션 테이블이로드되면 VARCHAR 열 크기를 대체로 변경할 수없는 것으로 고려해야합니다.
이미 훌륭한 답변에 대한 의견으로 :
먼저, 필드를 다음 varchar(240)과 같이 작성하고 나중에 더 긴 필드로 varchar(320)변경하려면이 변경은 물론 데이터베이스 제품에 따라 데이터베이스 서버에서 사소한 조작이어야합니다.
alter table Schema.Object alter column EmailAddress varchar(320) ;둘째, 평균 행 크기와 페이지 크기에 따라 varchar(320)대신 대신 사용 varchar(240)하면 할당 된 페이지 수 (실제 테이블에서 차지하는 디스크 공간)가 변경되지 않을 수 있습니다.
셋째, 위의 누군가가 이메일 주소 확인에 대해 이야기했습니다. 이메일 주소를 확인할 수있는 확실한 방법은 하나 뿐이며 이메일을 보내는 것입니다. :-)
DOMAINEnterprise Database 서버를 사용하는 경우 전자 메일 주소 DOMAIN를 어느 정도의 유효성 으로 저장해야합니다 . 도메인은 SQL 사양에 지정되어 있습니다
도메인은 데이터 유형을 지정할 수있는 특정 위치에서 데이터 유형의 대안으로 지정할 수있는 명명 된 사용자 정의 개체입니다. 도메인은 데이터 유형, 기본 옵션 및 0 개 이상의 도메인 제한으로 구성됩니다.
예를 들어, 무료 및 오픈 소스 PostgreSQL은 사양 구현에 제한이 없으며 열 자체에는 유효한 전자 메일이 포함되어 있습니다. 예를 들어 ..
DOMAIN이메일의 HTML5 사양에 대한 사용자 정의 를 작성하십시오 .DOMAIN확인시 서버에서 MX 레코드를 확인 하는 사용자 정의 를 작성 하십시오.PostgreSQL에만 해당되는이 답변 에서 이러한 옵션을 평가 합니다.