database - the - enviar email job sql server
¿Cuál es la longitud óptima para una dirección de correo electrónico en una base de datos? (8)
Aquí hay una parte extraída de mi consulta, que refleja el tipo de datos y la propiedad de la columna EMAIL_ADDRESS :
EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL,
Sin embargo, John Saunders usa VARYING(256) .
Esto me sugiere que no necesariamente he entendido la VARIACIÓN correctamente.
Lo entiendo de tal manera que la longitud de una dirección de correo electrónico es de 20 caracteres en mi caso, mientras que 256 para Jodn.
Contexto en el código 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)
);
Nunca he visto direcciones de correo electrónico de más de 20 caracteres, usadas por personas normales.
¿Cuál es la longitud óptima para una dirección de correo electrónico en una base de datos?
¡Mi dirección de correo electrónico de trabajo tiene más de 20 caracteres!
Lea la especificación RFC apropiada:
"La parte local de una dirección de correo electrónico puede tener hasta 64 caracteres y el nombre de dominio puede tener un máximo de 255 caracteres"
Como han dicho otros, mucho más que 20. 256 + 64 me suena bien y cumple con RFC.
La única razón para no tener un valor tan grande para su base de datos es si está preocupado por el rendimiento o el espacio, y si lo hace, entonces estoy 99.99999999999999% seguro de que es una optimización prematura .
Ve a lo grande.
Inicialmente, el máximo es de 320 caracteres (64 + 1 + 255, como se muestra en otras respuestas), pero como RFC 3696 Errata 1003 dijo:
Sin embargo, hay una restricción en RFC 2821 sobre la longitud de una dirección en los comandos MAIL y RCPT de 256 caracteres. Dado que las direcciones que no se ajustan a esos campos normalmente no son útiles, el límite superior de las longitudes de direcciones normalmente debe considerarse de 256.
Y de RFC 5321 sección 4.5.3.1.3 :
4.5.3.1.3. Camino
La longitud total máxima de una ruta inversa o una ruta directa es de 256 octetos (incluida la puntuación y los separadores de elementos)
Esto incluye los corchetes de apertura y cierre, por lo que solo nos permiten 254 octetos de dirección de correo electrónico.
Pero tenga en cuenta que el número de octetos puede no ser igual al número de caracteres (un char puede tener 2 o más octetos). También la sección 4.5.3.1 de RFC indica que puede haber campos de más que el máximo y esto es posible pero no garantizado para que los servidores los capturen correctamente.
Y luego puede / debe usar un VARCHAR(254) para almacenar una dirección de correo electrónico.
Nota: Al menos en MySQL, una columna declarada como VARCHAR con un número menor o igual a 255 octetos se almacenará como 1 byte + length (el 1 es para almacenar la longitud) por lo que no se gana espacio si se utiliza un límite inferior.
La longitud máxima de una dirección de correo electrónico es de 254 caracteres.
Cada dirección de correo electrónico se compone de dos partes. La parte local que aparece antes del signo ''@'' y la parte del dominio que lo sigue. En "[email protected]", la parte local es "usuario" y la parte de dominio es "ejemplo.com".
La parte local no debe superar los 64 caracteres y la parte del dominio no puede tener más de 255 caracteres.
La longitud combinada de las partes del dominio local + @ + de una dirección de correo electrónico no debe exceder los 254 caracteres. Como se describe en RFC3696 Errata ID 1690 .
Los tipos de caracteres variables en las bases de datos no ocupan espacio innecesario. Por lo tanto, no hay ninguna razón para restringir tales campos tanto como sea posible. Según el nombre de una persona, el esquema de nombres utilizado por su organización y su nombre de dominio, una dirección puede exceder fácilmente los 20 caracteres.
No hay límite en cuanto a la longitud de la parte local y el nombre de dominio en RFC-2822 . RFC-2181 embargo, RFC-2181 limita el nombre de dominio a 255 octetos / caracteres.
Nuevamente, dado que un varchar solo usa el espacio realmente usado por la cadena que almacena, no hay ninguna razón para tener un límite pequeño para la longitud de la dirección de correo electrónico. Solo ve con 512 y deja de preocuparte. Todo lo demás es una optimización prematura
Solo use varchar(50) . Los correos electrónicos más largos son basura, todo el tiempo.
Solo mira cuánto tiempo 50 caracteres es:
peoplewithanemail @ ddressthislongjustuseashorterone
Si permite 255 correos electrónicos de caracteres:
- Mostrarlos puede estropear su UI (en el mejor de los casos serán cortados, en el peor, empujarán sus contenedores y sus márgenes) y
- Los usuarios malintencionados pueden hacer cosas con ellos que no puedes anticipar (como los casos en que los piratas informáticos utilizaron una API en línea gratuita para almacenar una gran cantidad de datos)
(Las estadísticas muestran que, en realidad, nadie ingresa más de 50 caracteres para una dirección de correo legítima, consulte, por ejemplo, la respuesta del pageman https://.com/a/1199245/87861 )
Un campo CHAR (20) siempre ocupará 20 caracteres, ya sea que lo use todo o no. (A menudo rellenado con espacios al final). Un campo VARCHAR (20) ocupará hasta 20 caracteres, pero puede ocupar menos. Un beneficio del ancho constante de CHAR () es saltar rápidamente a una fila en una tabla, porque puede simplemente calcular el índice en el que debe estar. El inconveniente es perder espacio.
El beneficio de CHAR (x) de tamaño constante se pierde si tiene columnas VARCHAR (x) en su tabla. Me parece recordar que MySQL silenciosamente convirtió cualquier campo CHAR () en VARCHAR () detrás de las escenas si algunas columnas eran VARCHAR () s.
de Ask Metafilter :
Mis datos provienen de una base de datos de 323 direcciones. La distribución tiene algunos valores atípicos de extremo superior (positivamente sesgados). Normalmente se distribuye sin los valores atípicos (lo probé).
Min: 12 1er cuartil: 19 Media (sin valores atípicos): 23,04 Media sin valores atípicos): 22,79 3er cuartil: 26 Máx. (Con valores atípicos): 47 Máx. (Sin datos atípicos): 35
Mediana: 23 Modo: 24 Std. Dev (w / outliers): 5.20 Std. Dev (sin valores atípicos): 4.70
Rangos basados en datos que incluyen valores atípicos 68,2% de los datos 17,8 - 28,2 95,4% de los datos 12,6 - 33,4 99,7% de los datos 7,4 - 38,6
Los rangos basados en datos atípicos excluyeron el 68.2% de los datos 18.1 - 27.5 95.4% de los datos 13.4 - 32.2 99.7% de los datos 8.7 - 36.9
Si te registras en http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/ entonces tu dirección de correo electrónico seguramente será un valor atípico :)
Aquí está ¿Cuál es la duración máxima segura de una dirección de correo electrónico para permitir en un formulario de sitio web? en Raycon con una media ligeramente diferente (N = 50.496, media = 23):
