Me preguntaba cuáles serían las consecuencias de establecer campos NVARCHAR en MAX en lugar de un tamaño específico en SQL Server 2008, y limitar la entrada de la lógica de la aplicación. Además, ¿sería ésta una mala práctica de diseño?¿Limitar el tamaño de NVARCHAR en SQLServer?
NVARCHAR (MAX) es mucho mejor en rendimiento con datos más pequeños que el antiguo tipo de datos NTEXT, sin embargo, NVARCHAR (n) siempre será más eficiente en algunas áreas.
Como regla general, usar el tipo de datos que mejor represente los datos que está almacenando es casi siempre la mejor práctica.
No debe establecer todos sus campos en NVARCHAR (MAX) si sabe que nunca tendrán más de un número finito de caracteres debido a la forma en que SQL almacena este tipo de datos, datos lo suficientemente pequeños como para caber en la página se almacenará en la página, pero cuando crezca demasiado, se moverá de la página y se almacenará por separado.
Además, ¿está seguro de que necesita NVARCHAR ya que almacena datos Unicode que ocupan el doble del espacio del VARCHAR estándar? Si sabe, utilizará caracteres estándar y luego usará VARCHAR.
Slo, piense en los usos de su aplicación. Si tiene un campo de dirección que no tiene un límite teórico sobre su tamaño, ¿cómo lo imprimiría en su sobre? Usted dice que implementará la lógica en la aplicación frontal, pero ¿por qué todavía permite que la base de datos tenga datos demasiado grandes? ¿Y qué sucede si los datos entran en la base de datos que rompe la lógica en su interfaz?
Hay un montón de performance implications. En particular, en un UDF escalar de relleno de cadena de uso general, noté enormes diferencias de rendimiento donde la salida se declaró como VARCHAR (MAX), incluso aunque las entradas nunca fueran> 40 caracteres. Cambiar a VARCHAR (50) hizo una GRAN mejora.
El principal inconveniente es que NVARCHAR(MAX) no se puede indexar con índices simples.
Además, hay algunos problemas con las variables de tipo NVARCHAR(MAX) y con el rendimiento de las funciones que analizan estas variables.
Si solo desea almacenar y recuperar datos tal como están, y no analizarlos en el lado SQL Server, entonces NVARCHAR(MAX) está bien.
Seting un límite tiene un efecto secundario de algunos de validación de la longitud máx
Sólo para complementar todas las otras respuestas: ser también cuidadoso de los escenarios en los que los datos pueden provenir de otras fuentes, como - como un ejemplo - archivos de texto importados desde fuera de sus aplicaciones; esto podría pasar por alto cualquier lógica de aplicación, a menos que la duplique en las rutinas de importación ...
Excelente punto que muchos desarrolladores de aplicaciones olvidan, hay muchas formas en que los datos entran en una base de datos, toda la validación requerida debe realizarse allí a menos que desee problemas de integridad de datos. – HLGEM
Necesito NVARCHAR, son posibles los caracteres 'exóticos'. – kjv
+1 para la primera declaración. -1 por segundo. Aunque es absolutamente correcto que nvarchar use el doble del espacio de varchar, estar absolutamente seguro de que solo usará caracteres "estándar" es una suposición importante, fácilmente derrotada por, por ejemplo, campos con palabras extranjeras como nombres que contienen caracteres "extraños" . No estoy seguro de que mantener la suposición se pague en términos de espacio en disco y memoria, que es más barato por día, en comparación con el dolor de cabeza que puede traer. –
No estoy de acuerdo, es incorrecto poner limitaciones en el db. El software siempre debe manejar la validación y la base de datos tiene la libertad de crecer cuando sea necesario sin ningún cambio en la base de datos. – freggel