nvarchar (max) vs NText

¿Cuáles son las ventajas y desventajas de usar los tipos de datos nvarchar(max)vs. NTexten SQL Server? No necesito compatibilidad con versiones anteriores, por lo que está bien que nvarchar(max)no sea compatible con versiones anteriores de SQL Server.

Editar: Aparentemente, la pregunta también se aplica a TEXTy IMAGEvs. varchar(max)y varbinary(max), para aquellos que buscan esos tipos de datos más adelante.

Las ventajas son que puede usar funciones como LENy LEFTen nvarchar(max)y no puede hacerlo contra ntexty text. También es más fácil trabajar con el nvarchar(max)que texttenía que usar WRITETEXTy UPDATETEXT.

Además, text, ntext, etc., están siendo obsoleta ( http://msdn.microsoft.com/en-us/library/ms187993.aspx )

VARCHAR(MAX)es lo suficientemente grande como para acomodar el TEXTcampo. TEXT, NTEXTy IMAGElos tipos de datos de SQL Server 2000 quedarán en desuso en futuras versiones de SQL Server, SQL Server 2005 proporciona compatibilidad con versiones anteriores de los tipos de datos, pero se recomienda utilizar nuevos tipos de datos que son VARCHAR(MAX), NVARCHAR(MAX)y VARBINARY(MAX).

ntextsiempre almacenará sus datos en una página de base de datos separada, mientras nvarchar(max)que intentará almacenar los datos dentro del registro de la base de datos.

Por nvarchar(max)lo tanto, es algo más rápido (si tiene texto que es más pequeño que 8 kB). También noté que el tamaño de la base de datos crecerá un poco más lento, esto también es bueno.

Ir nvarchar(max).

nvarchar(max)es lo que quieres usar. La mayor ventaja es que puede usar todas las funciones de cadena T-SQL en este tipo de datos. Esto no es posible con ntext. No conozco ninguna desventaja real.

Aparentemente deberías usar nvarchar(max):

MSDN

La mayor desventaja de Text(junto con NTexty Image) es que se eliminará en una versión futura de SQL Server, como se indica en la documentación . Eso hará que su esquema sea más difícil de actualizar cuando se lance esa versión de SQL Server.

Quería agregar mi experiencia con la conversión. Tenía muchos textcampos en el antiguo código Linq2SQL. Esto era para permitir que las textcolumnas presentes en los índices se reconstruyeran EN LÍNEA .

Primero, conocí los beneficios durante años, pero siempre asumí que la conversión significaría algunas consultas largas y aterradoras en las que SQL Server tendría que reconstruir la tabla y copiar todo, derribar mis sitios web y aumentar mi ritmo cardíaco.

También me preocupaba que Linq2SQL pudiera causar errores si estaba haciendo algún tipo de verificación del tipo de columna.

Sin embargo, me complace informar que los comandos ALTER regresaron INSTANTÁNEAMENTE, por lo que definitivamente solo están cambiando los metadatos de la tabla. Puede haber algún trabajo fuera de línea para que los datos de <8000 caracteres vuelvan a estar en la tabla, pero el comando ALTER fue instantáneo.

Ejecuté lo siguiente para encontrar todas las columnas que necesitan conversión:

SELECT concat('ALTER TABLE dbo.[', table_name, '] ALTER COLUMN [', column_name, '] VARCHAR(MAX)'), table_name, column_name
FROM information_schema.columns where data_type = 'TEXT' order by table_name, column_name

SELECT concat('ALTER TABLE dbo.[', table_name, '] ALTER COLUMN [', column_name, '] NVARCHAR(MAX)'), table_name, column_name
FROM information_schema.columns where data_type = 'NTEXT' order by table_name, column_name

Esto me dio una buena lista de consultas, que acabo de seleccionar y copiar en una nueva ventana. Como dije, ejecutar esto fue instantáneo.

Linq2SQL es bastante antiguo: utiliza un diseñador al que arrastra las tablas. La situación puede ser más compleja para EF Code primero, pero aún no lo he abordado.

Quiero agregar que puede usar la cláusula .WRITE para actualizaciones parciales o completas y el alto rendimiento se agrega a varchar(max)/nvarchar(max)los tipos de datos.

Aquí puede encontrar un ejemplo completo del uso de la .WRITEcláusula.