Quelle est la longueur optimale pour une adresse e-mail dans une base de données?

Question

Je suis en train de faire mon premier projet de base de données.

J'ai la requête suivante dans la colonne de EMAIL_ADDRESS:

...
EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL, 
...

Cependant, John Saunders utilise VARYING(256). Cela suggère que moi que je n'ai pas forcément compris les VARIABLES correctement. Je comprends que la longueur d'une adresse e-mail est de 20 caractères dans mon cas, tandis que 256 pour Jodn.

Contexte dans Jean du code

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)
     );

Je n'ai jamais vu adresses e-mail de plus de 20 caractères, utilisé par les gens ordinaires.

Quelle est la longueur optimale pour une adresse e-mail dans une base de données?

Answer 1

La longueur maximale d'une adresse e-mail est de 254 caractères.

Chaque adresse e-mail est composé de deux parties. La partie locale qui vient avant le signe'@', et le nom de domaine qui le suit. Dans "user@example.com", la partie locale est "user", et le nom de domaine est "example.com".

La partie locale ne doit pas dépasser 64 caractères et le nom de domaine ne peut pas être de plus de 255 caractères.

La longueur combinée du local + @ + domaine des pièces d'une adresse e-mail ne doit pas dépasser 254 caractères. Comme décrit dans RFC3696 Errata ID 1690.

Je l'ai eu à l'origine une partie de cette information à partir d'ici

Answer 2

de Demander Metafilter:

Mes données proviennent d'une base de données de 323 les adresses. La distribution a certains haut de gamme des valeurs aberrantes (positivement asymétrique -). Il est normalement distribué sans l'valeurs aberrantes (je mise à l'épreuve.)

Min: 12 1er quartile: 19 Moyenne (w/ les valeurs aberrantes): 23.04 Moyenne w/o des valeurs aberrantes): 22.79 3e quartile: 26 Max (w/ valeurs aberrantes): 47 Max (w/o des valeurs aberrantes): 35

Médiane: 23 Mode: 24 Std. Dev (w/ les valeurs aberrantes): 5.20 Std. Dev (w/o les valeurs aberrantes): 4.70

Fourchette sur la base de données, y compris les valeurs aberrantes 68.2% des données de 17,8 - 28.2 95,4% des données de 12,6 - 33.4 99,7% des données 7.4 - 38.6

Gammes basées sur des données aberrantes exclus 68.2% des données 18.1 - 27.5 95,4% des données 13.4 - 32.2 99,7% des données de 8,7 - 36.9

et si vous vous inscrivez pour http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/ puis votre adresse e-mail serait certainement une valeur aberrante :)

voici un autre site avec un peu différente de la moyenne (N=50,496, moyenne=23):

Answer 3

Mon adresse e-mail professionnelle est de plus de 20 caractères!

Lire le RFC:

"Le local-la partie d'une adresse e-mail peut-être jusqu'à 64 caractères et le nom de domaine peut avoir un maximum de 255 caractères"

Answer 4

Variable de types de caractères dans les bases de données ne monopolise pas inutile de l'espace. Ainsi, il n'y a pas de raison de limiter un tel champs autant que possible. Selon le nom d'une personne, le schéma de nommage utilisé par leur organisation et de leur nom de domaine, une adresse peut facilement dépasser 20 caractères.

Il n'y a pas de limite quant à la durée du local-part et de nom de domaine dans la RFC-2822. RFC 2181 limites le nom de domaine à 255 octets de caractères/si.

De nouveau, depuis un varchar utilise uniquement à l'espace réellement utilisé par la chaîne de magasin, il n'y a pas de raison d'avoir une petite limite pour l'adresse de courriel de la longueur. Juste aller avec 512 et arrêtez de vous inquiéter. Tout le reste est de l'optimisation prématurée

Answer 5

Comme d'autres l'ont dit, plus grand que 20. 256 + 64 sonne bien pour moi, et est conforme à la RFC.

La seule raison pour pas avoir une grande valeur pour votre base de données est si vous vous faites du souci à propos de la performance ou de l'espace, et si vous faites cela, alors je suis 99.99999999999999% sûr que c'est de l'optimisation prématurée.

Allez-y en grand.