nchar vs nvarchar rendimiento

Question

¿Cómo se decidió si se usaron nvarchar o nchar?

Por ejemplo he notado que la base de datos de miembros predeterminada creada por el proveedor sqlmembership declara la columna de correo electrónico a ser de tipo nvarchar (256)

Para mí que parece una innecesariamente grande valor máximo de una columna de correo electrónico. Sospecho que, en circunstancias normales, los correos electrónicos de más de 40 o 50 caracteres serían bastante raros.

Pero, dado que los datos como las direcciones de correo electrónico varían en longitud, ¿siempre se deben almacenar como nvarchar para eliminar el espacio redundante?

Si usa nvarchar para una columna de correo electrónico. En el caso de que se cambie una dirección de correo electrónico, si el nuevo correo electrónico es más largo que el correo electrónico anterior, ¿esto causará muchas divisiones de páginas y, por lo tanto, gran parte de un costo de rendimiento?

¿Alguna vez consideraría utilizar nchar (40) para una dirección de correo electrónico y comprometería la pérdida de espacio de almacenamiento a cambio de que no haya costos de rendimiento de división de página?

¿O el uso de nchar (40) aumentaría significativamente el tamaño de la base de datos provocando así otros impactos de rendimiento en la velocidad de la consulta?

¿Utilizaría nchar solo cuando sepa el tamaño de los datos para completar la columna? ¿Sería una regla razonable a seguir?

Answer 1

mensajes de correo electrónico de más de 40 o 50 caracteres serían bastante raro

Sólo se necesita un arruinar su modelo ...

si el nuevo correo electrónico es más largo que el anterior correo electrónico Esto causará muchas divisiones de página

No. Pero incluso si lo hizo, no es así como se diseña el modelo de datos. Digamos, por el bien de la discusión, que cada vez que un correo electrónico se actualiza, provocará una división de la página. ¿Optimizarías para ese? No, porque preasignar un gran tamaño fijo (es decir, usando un NCHAR (256)) es mucho peor, de hecho elimina la división de página potencial en la actualización (de nuevo, si tal división de página sería) pero en el el costo mucho peor de aumentar el tamaño de la tabla, que se traduce en el ancho de banda IO y el consumo memoy, ver Disk space is cheap...THAT'S NOT THE POINT!!!.

¿Por qué digo que las actualizaciones de longitud variable no causan divisiones de página? Porque las divisiones de página se fuerzan cuando la imagen de la fila ya no cabe en la página. Una actualización de una columna de longitud variable probablemente provocará un desbordamiento de fila y dejará la fila en el mismo tamaño que antes, o incluso más pequeña. Hay casos en que la fila aumentará de tamaño después del desbordamiento, pero hay varias condiciones para que esto se desencadenan en realidad una división de página:

• la actualización de valor tiene que provocar un aumento de tamaño de la fila, esto sólo puede suceder cuando se actualiza desde un valor menor que el puntero de 24 bytes descrito en Table and Index Organization a un valor mayor que este tamaño de puntero.
• el aumento en el tamaño de fila (que por definición tiene un incremento de 24 bytes como máximo para cada columna de variable que se actualiza, incluidas las actualizaciones de NULL a no NULL) tiene que dar como resultado una fila que no cabe en la página.
• no debe haber espacio posible recuperar en la fila de empujar otros campos fuera de la fila (es decir. Todos los campos de longitud variable ya son empujados fuera de la fila)

Realmente no comprar que tiene una carga de trabajo tan extraño y esotérico como las condiciones mencionadas a hacerse el factor principal en la conducción de su diseño. Use una NVARCHAR de longitud conveniente para acomodar cualquier valor que encuentre.