Siempre he usado 320 según su último cálculo. No le cuesta nada permitir más *, a menos que la gente lo abuse y guarde basura allí. Es podría le costó permitir menos, ya que tendrá usuarios frustrantes si tienen direcciones de correo electrónico legítimamente más largas y ahora tendrá que volver y actualizar el esquema, el código, los parámetros, etc. En el sistema que utilicé para trabajar con (un proveedor de servicios de correo electrónico), la dirección de correo electrónico más larga que encontré fue de 120 caracteres, y estaba claro que solo estaban haciendo una larga dirección de correo electrónico para sonrisas.
* No es del todo cierto, ya que las estimaciones de concesión de memoria se basan en la suposición de que la variación de ancho de columnas son la mitad de población, por lo que una columna más ancha almacenar los mismos datos puede tener lugar a muy diferentes características de rendimiento de algunas consultas .
Y he discutiendo si NVARCHAR es necesario para la dirección de correo electrónico. Todavía tengo que encontrar una dirección de correo electrónico con caracteres Unicode: sé que el estándar los admite, pero muchos sistemas existentes no lo hacen, sería bastante frustrante si esa fuera su dirección de correo electrónico.
Y si bien es cierto que NVARCHAR costes doble de espacio, con SQL Server 2008 R2 se puede beneficiar de la compresión Unicode, que básicamente trata a todos los caracteres no Unicode en una columna NVARCHAR como ASCII, para que pueda obtener los bytes adicionales espalda. Por supuesto, la compresión solo está disponible en Enterprise + ...
Otra forma de reducir los requisitos de espacio es utilizar una tabla central de búsqueda para todos los nombres de dominio observados, y almacenar LocalPart y DomainID con el usuario y almacenar cada nombre de dominio exclusivo una vez. Sí, esto hace que la programación sea más engorrosa, pero si tiene 80,000 direcciones de hotmail.com, el costo es 80,0000 x 4 bytes en lugar de 80,000 x 11 bytes (o menos con compresión).Si el almacenamiento o E/S es su cuello de botella, y no la CPU, esta es definitivamente una opción que vale la pena investigar.
Escribí sobre esto aquí:
http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/
@tugberk lo siento en el retraso de notificación, pero escribí sobre esto aquí: http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/ –
Sólo para info: ASP.NET membership provider create database "AspNetUsers" usando "nvarchar (256)" para el campo Email. – Yanga
@Yanga ugh, gracias por eso. –