Quelle est la longueur optimale pour une adresse e-mail dans une base de données?
Voici une partie extraite de ma requête, reflétant le type de données et la propriété de la colonne EMAIL_ADDRESS:
EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL,
Cependant, John Saunders utilise VARYING(256).
Cela me donne à penser que je n'ai pas nécessairement bien compris la VARIATION.
Je comprends que la longueur d'une adresse e-mail soit de 20 caractères dans mon cas, tandis que 256 pour Jodn.
Contexte dans le code de John
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 pour 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 domaine qui le suit. Dans "[email protected]", la partie locale est "user" et la partie domaine est "example.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 169 .
de Ask Metafilter :
Mes données proviennent d'une base de données de 323 adresses. La distribution présente des valeurs aberrantes supérieures (asymétriques positives). 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 les données, y compris les 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
Les fourchettes basées sur les données aberrantes excluent 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/ alors votre adresse e-mail serait sûrement une valeur aberrante :)
Voici Quelle est la longueur maximale sécurisée 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):
Utilisez simplement varchar(50). Les courriels plus longs sont de la merde, à chaque fois.
Regardez la longueur de 50 caractères:
peoplewithanemail @ ddressthislongjustuseashorterone
Si vous autorisez 255 e-mails de caractères:
- Les afficher peut perturber votre interface utilisateur (au mieux, ils seront coupés, au pire, ils pousseront vos conteneurs et vos marges) et
- Les utilisateurs malveillants peuvent faire avec eux des choses que vous ne pouvez pas prévoir (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 ne saisit plus de 50 caractères pour une adresse e-mail légitime, voir par exemple: la réponse de pageman https://stackoverflow.com/a/1199245/87861 )
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 limiter autant que possible ces champs. Selon le nom d'une personne, le schéma de nommage utilisé par son organisation et 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 RFC-2822 . RFC-2181 limite cependant le nom de domaine à 255 octets/caractères.
Encore une fois, puisqu'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-y avec 512 et arrêtez de vous inquiéter. Tout le reste est optimisation prématurée
Initialement, le maximum est de 320 caractères (64 + 1 + 255, comme indiqué dans d'autres réponses) mais comme RFC 3696 Errata 10 dit:
Cependant, il y a une restriction dans 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 de la longueur des adresses doit normalement être considérée comme 256.
Et de RFC 5321 section 4.5.3.1. :
4.5.3.1.3. Chemin
La longueur totale maximale d'un chemin inverse ou direct est de 256 octets (y compris la ponctuation et les séparateurs d'éléments)
Cela inclut les parenthèses d'ouverture et de fermeture, ce qui nous permet de ne 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). De plus, les RFC section 4.5.3.1 indiquent qu'il peut y avoir des champs de plus que le maximum et cela est possible mais pas garanti aux serveurs pour les attraper correctement.
Et puis vous pouvez/devez utiliser une VARCHAR(254) pour stocker une adresse e-mail.
Remarque: Dans MySQL au moins, une colonne déclarée comme VARCHAR avec moins ou égal à 255 octets sera stockée comme 1 byte + length (le 1 est pour stocker la longueur) donc aucun espace n'est gagné si on utilise une limite inférieure.
Comme d'autres l'ont dit, bien plus grand que 20. 256 + 64 me semble bien et est compatible 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 sûr à 99,9999999999999999% que optimisation prématurée.
Aller en grand.
Un champ CHAR (20) prendra toujours 20 caractères, que vous l'utilisiez tout ou non. (Souvent complété par des espaces à la fin.) Un champ VARCHAR (20) prendra jusqu'à 20 caractères, mais peut prendre moins. Un avantage de la largeur constante de CHAR () est le saut rapide vers une ligne dans une table, car vous pouvez simplement calculer l'index sur lequel il 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 silencieusement converti tous les champs CHAR () en VARCHAR () dans les coulisses si certaines colonnes étaient des VARCHAR ().