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

Voici une partie extraite de ma requête, reflétant le EMAIL_ADDRESStype de données et la propriété de la colonne:

EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL, 

Cependant, John Saunders utilise VARYING(256).

Cela me suggère que je n'ai pas nécessairement compris correctement le VARYING.

Je comprends que la longueur d'une adresse e-mail soit de 20 caractères dans mon cas, alors que 256 pour Jodn.

Contexte dans le code de Jean

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 d'adresses e-mail de plus de 20 caractères, utilisées par des gens ordinaires.

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

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

Chaque adresse e-mail est composée de deux parties. La partie locale qui précède le signe «@» et la partie de domaine qui le suit. Dans "utilisateur@exemple.com", la partie locale est "utilisateur" et la partie domaine est "exemple.com".

La partie locale ne doit pas dépasser 64 caractères et la partie domaine ne peut pas dépasser 255 caractères.

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

J'ai obtenu la partie originale de ces informations d'ici

de Ask Metafilter :

Mes données proviennent d'une base de données de 323 adresses. La distribution a des valeurs aberrantes supérieures (biaisées positivement). Il est normalement distribué sans les valeurs aberrantes (je l'ai testé.)

Min: 12 1er quartile: 19 Moyenne (sans valeurs aberrantes): 23,04 Moyenne sans valeurs aberrantes): 22,79 3e quartile: 26 Max (sans valeurs aberrantes): 47 Max (sans valeurs aberrantes): 35

Médiane: 23 Mode: 24 Std. Dev (avec valeurs aberrantes): 5,20 Std. Dev (sans valeurs aberrantes): 4,70

Plages basées sur des données incluant des valeurs aberrantes 68,2% des données 17,8 - 28,2 95,4% des données 12,6 - 33,4 99,7% des données 7,4 - 38,6

Plages basées sur les données aberrantes exclues 68,2% des données 18,1 - 27,5 95,4% des données 13,4 - 32,2 99,7% des données 8,7 - 36,9

Si vous vous inscrivez à http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/, votre adresse e-mail serait sûrement une valeur aberrante :)

Voici Quelle est la longueur maximale de sécurité d'une adresse e-mail à autoriser dans un formulaire de site Web? sur Raycon avec une moyenne légèrement différente (N = 50,496, moyenne = 23):

Juste utiliser varchar(50) . Les e-mails plus longs sont de la merde, à chaque fois.

Regardez la longueur de 50 caractères:

peoplewithanemail @ ddressthislongjustuseashorterone

Si vous autorisez les e-mails de 255 caractères:

• Les afficher peut gâcher votre interface utilisateur (au mieux, ils seront coupés, au pire, ils poussent vos conteneurs et vos marges) et
• Les utilisateurs malveillants peuvent faire des choses avec eux que vous ne pouvez pas anticiper (comme les cas où les pirates ont utilisé une API en ligne gratuite pour stocker un tas de données)

(Les statistiques montrent que personne n'entre réellement plus d'environ 50 caractères pour une adresse e-mail légitime, voir par exemple: la réponse du pageman https://stackoverflow.com/a/1199245/87861 )

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

Lisez la spécification RFC appropriée :

"La partie locale d'une adresse e-mail peut contenir jusqu'à 64 caractères et le nom de domaine peut avoir un maximum de 255 caractères"

Les types de caractères variables dans les bases de données n'occupent pas d'espace inutile. Il n'y a donc aucune raison de restreindre autant que possible ces champs. En fonction du nom d'une personne, du schéma de dénomination utilisé par son organisation et de son nom de domaine, une adresse peut facilement dépasser 20 caractères.

Il n'y a pas de limite quant à la longueur de la partie locale et du nom de domaine dans la RFC-2822 . La RFC-2181 limite le nom de domaine à 255 octets / caractères.

Encore une fois, comme un varchar utilise uniquement l'espace réellement utilisé par la chaîne que vous stockez, il n'y a aucune raison d'avoir une petite limite pour la longueur de l'adresse e-mail. Allez simplement avec 512 et arrêtez de vous inquiéter. Tout le reste est une optimisation prématurée

Initialement, le maximum est de 320 caractères (64 + 1 + 255, comme indiqué dans d'autres réponses) mais comme le dit RFC 3696 Errata 1003 :

Cependant, il existe une restriction dans la RFC 2821 sur la longueur d'une adresse dans les commandes MAIL et RCPT de 256 caractères. Étant donné que les adresses qui ne rentrent pas dans ces champs ne sont normalement pas utiles, la limite supérieure des longueurs d'adresse doit normalement être considérée comme étant de 256.

Et à partir de la section 4.5.3.1.3 de la RFC 5321 :

4.5.3.1.3. Chemin

La longueur totale maximale d'un chemin inverse ou aller est de 256 octets (y compris la ponctuation et les séparateurs d'éléments)

Cela inclut les crochets d'ouverture et de fermeture, donc il ne nous laisse que 254 octets d'adresse e-mail.

Mais gardez à l'esprit que le nombre d'octets peut ne pas être égal au nombre de caractères (un caractère peut avoir 2 octets ou plus). Aussi la section 4.5.3.1 RFC indique qu'il peut y avoir des champs de plus que le maximum et c'est possible mais non garanti aux serveurs de les attraper correctement.

Et puis vous pouvez / devez utiliser un VARCHAR(254) pour stocker une adresse e-mail.

Remarque: Dans MySQL au moins, une colonne déclarée comme étant VARCHARinférieure ou égale à 255 octets sera entièrement stockée en tant que 1 byte + length(le 1 est de stocker la longueur) donc aucun espace n'est gagné si une limite inférieure est utilisée.

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

La seule raison de ne pas avoir une valeur aussi élevée pour votre base de données est si vous vous inquiétez des performances ou de l'espace, et si vous le faites, je suis 99,99999999999999% sûr que c'est une optimisation prématurée. .

Aller en grand.

Un champ CHAR (20) prendra toujours 20 caractères, que vous l'utilisiez entièrement ou non. (Souvent rembourré avec des espaces à la fin.) Un champ VARCHAR (20) prendra jusqu'à 20 caractères, mais peut prendre moins. L'un des avantages de la largeur constante de CHAR () est le passage rapide à une ligne dans une table, car vous pouvez simplement calculer l'index sur lequel elle doit être. L'inconvénient est de perdre de l'espace.

L'avantage des CHAR (x) de taille constante est perdu si vous avez des colonnes VARCHAR (x) dans votre table. Je semble me rappeler que MySQL a converti silencieusement tous les champs CHAR () en VARCHAR () dans les coulisses si certaines colonnes étaient des VARCHAR ().