Veritabanındaki bir e-posta adresi için en uygun uzunluk nedir?

Sorgumun EMAIL_ADDRESSsütun veri türünü ve özelliğini yansıtan çıkarılmış bir kısmı :

EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL, 

Ancak John Saunders kullanır VARYING(256).

Bu bana, VARYING'i doğru olarak anlamam gerekmediğini gösteriyor.

Benim durumumda bir e-posta adresinin uzunluğunun 20 karakter, Jodn için ise 256 karakter olduğunu anlıyorum.

John'un kodundaki bağlam

CREATE TABLE so."User"
  (
    USER_ID SERIAL NOT NULL,
    USER_NAME CHARACTER VARYING(50) NOT NULL,
    EMAIL_ADDRESS CHARACTER VARYING(256) NOT NULL, // Here
    HASHED_PASSWORD so.HashedPassword NOT NULL,
    OPEN_ID CHARACTER VARYING(512),                                                         
    A_MODERATOR BOOLEAN,
    LOGGED_IN BOOLEAN,
    HAS_BEEN_SENT_A_MODERATOR_MESSAGE BOOLEAN,
    CONSTRAINT User_PK PRIMARY KEY(USER_ID)
  );

Sıradan insanlar tarafından kullanılan 20 karakterden uzun e-posta adreslerini hiç görmedim.

Veritabanındaki bir e-posta adresi için en uygun uzunluk nedir?

Bir e-posta adresinin maksimum uzunluğu 254 karakterdir.

Her e-posta adresi iki bölümden oluşur. '@' İşaretinden önce gelen yerel kısım ve onu izleyen alan kısmı. "Kullanıcı@example.com" da yerel kısım "kullanıcı" ve alan kısmı "example.com" dur.

Yerel kısım 64 karakteri geçmemelidir ve etki alanı kısmı 255 karakterden uzun olamaz.

Bir e-posta adresinin yerel + @ + etki alanı bölümlerinin toplam uzunluğu 254 karakteri geçmemelidir. RFC3696 Hata Kimliği 1690'da açıklandığı gibi .

Bu bilginin orijinal kısmını buradan aldım

dan Metafilter Ask :

Verilerim 323 adreslik bir veritabanından geliyor. Dağılımın bazı üst uç aykırı değerleri vardır (pozitif çarpık). Normalde aykırı değerler olmadan dağıtılır (test ettim.)

Min: 12 1. çeyrek: 19 Ortalama (aykırı değerler): 23.04 Ortalama aykırı değerler): 22.79 3. çeyrek: 26 Maks (aykırı değerler ile): 47 Maks (aykırı değerler hariç): 35

Medyan: 23 Mod: 24 Std. Dev (aykırı değerlerle): 5.20 Std. Dev (aykırı değerler hariç): 4,70

Aykırı değerleri içeren verilere dayalı aralıklar Verilerin% 68,2'si 17,8 - 28,2 Verilerin% 95,4'ü 12,6 - 33,4% 99,7'si 7,4 - 38,6

Veri aykırı değerlerine dayalı aralıklar verinin% 68,2'sini hariç tuttu 18,1 - 27,5 Verinin% 95,4'ü 13,4 - 32,2 Verinin% 99,7'si 8.7 - 36.9

Http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/ için kaydolursanız , e-posta adresiniz kesinlikle aykırı olacaktır :)

İşte bir web sitesi şeklinde izin e-posta adresi maksimum güvenli uzunluğu nedir? Raycon üzerinde biraz farklı bir ortalamaya sahip (N = 50,496, ortalama = 23):

Sadece kullan varchar(50). Her seferinde daha uzun e-postalar saçmadır.

50 karakterin ne kadar uzun olduğuna bir bakın:

insanlarwithanemail @ ddressthislongjustuseashorterone

255 karakterlik e-postalara izin verirseniz:

• Bunları görüntülemek, kullanıcı arayüzünüzü bozabilir (en iyi ihtimalle kesilecekler, en kötü ihtimalle kapsayıcılarınızı ve kenar boşluklarınızı iteceklerdir) ve
• Kötü niyetli kullanıcılar onlarla tahmin edemeyeceğiniz şeyler yapabilir (bilgisayar korsanlarının bir sürü veriyi depolamak için ücretsiz bir çevrimiçi API kullandığı durumlar gibi)

(İstatistikler, gerçekte hiç kimsenin yasal bir e-posta adresi için yaklaşık 50 karakterden fazlasını girmediğini göstermektedir, örneğin bkz: pageman'ın cevabı https://stackoverflow.com/a/1199245/87861 )

İş e-posta adresim 20 karakterden fazla!

Uygun RFC spesifikasyonunu okuyun :

"Bir e-posta adresinin yerel kısmı en fazla 64 karakter uzunluğunda olabilir ve alan adı maksimum 255 karaktere sahip olabilir"

Veritabanlarındaki değişken karakter türleri gereksiz yere yer kaplamaz. Bu nedenle, bu tür alanları olabildiğince kısıtlamak için hiçbir neden yoktur. Bir kişinin adına, organizasyonu tarafından kullanılan adlandırma şemasına ve etki alanı adına bağlı olarak, bir adres kolayca 20 karakteri aşabilir.

RFC-2822'de yerel bölüm ve etki alanı adının uzunluğuna ilişkin bir sınırlama yoktur . RFC-2181 , etki alanı adını 255 sekizli / karakterle sınırlar.

Yine, bir varchar yalnızca depoladığınız dizge tarafından gerçekten kullanılan alanı kullandığından, e-posta adresi uzunluğu için küçük bir sınıra sahip olmak için bir neden yoktur. Sadece 512 ile gidin ve endişelenmeyi bırakın. Diğer her şey erken optimizasyondur

Başlangıçta maksimum 320 karakterdir (diğer cevaplarda gösterildiği gibi 64 + 1 + 255), ancak RFC 3696 Errata 1003'ün dediği gibi:

Ancak, RFC 2821'de, MAIL ve RCPT komutlarındaki 256 karakterlik bir adresin uzunluğu konusunda bir kısıtlama vardır. Bu alanlara uymayan adresler normalde kullanışlı olmadığından, adres uzunluklarına ilişkin üst sınır normalde 256 olarak kabul edilmelidir.

Ve aralarından RFC 5321 bölüm 4.5.3.1.3 :

4.5.3.1.3. Yol

Bir ters yol veya ileri yolun maksimum toplam uzunluğu 256 sekizlidir (noktalama işaretleri ve öğe ayırıcılar dahil)

Bu, açılış ve kapanış parantezlerini içerir, bu nedenle bize yalnızca 254 sekizli e-posta adresine izin verir .

Ancak sekizli sayısının karakter sayısına eşit olmayabileceğini unutmayın (bir karakterde 2 veya daha fazla sekizli olabilir). Ayrıca RFC bölüm 4.5.3.1 , maksimumdan daha fazla alan olabileceğini ve bunun mümkün olduğunu, ancak sunuculara bunları doğru şekilde yakalamaları için garanti olmadığını söyler.

Ve sonra VARCHAR(254)bir e-posta adresini saklamak için a kullanabilir / kullanmalısınız .

Not: En azından VARCHARMySQL'de, 255 sekizliden daha az veya ona eşit whit olarak bildirilen bir sütunun tümü olarak saklanacaktır 1 byte + length(1 uzunluğu saklamak içindir), bu nedenle daha düşük bir limit kullanılırsa alan kazanılmaz.

Diğerlerinin de söylediği gibi, 20'den çok daha büyük. 256 + 64 kulağa hoş geliyor ve RFC uyumlu.

Veritabanınız için bu kadar büyük bir değere sahip olmamanın tek nedeni, performans veya alan hakkında endişeleniyorsanız ve bunu yapıyorsanız, bunun erken optimizasyon olduğundan% 99.99999999999999 eminim .

Büyük oyna.

Bir CHAR (20) alanı, hepsini kullansanız da kullanmasanız da, her zaman 20 karakter alacaktır. (Genellikle sonunda boşluklarla doldurulur.) Bir VARCHAR (20) alanı kaplar kadar 20 karakter, ancak daha az kadar sürebilir. CHAR () sabit genişliğinin bir faydası, tablodaki bir satıra hızlı bir şekilde atlamaktır, çünkü sadece üzerinde olması gereken dizini hesaplayabilirsiniz. Dezavantajı boşa harcamaktır.

Tablonuzda herhangi bir VARCHAR (x) sütunu varsa, sabit boyutlu CHAR (x) 'lerin yararı kaybolur. MySQL'in herhangi bir CHAR () alanını, bazı sütunlar VARCHAR () s ise, perde arkasında sessizce VARCHAR () 'a dönüştürdüğünü hatırlıyorum.