¿Cómo almacenará nvarchar (max) los datos en la base de datos? ¿Será rápido si algunos datos tienen menos de 4000 caracteres?

Tengo que desarrollar un CMS que admita dos idiomas inglés, árabe. Este CMS será una especie de sitio de publicación de artículos. Mientras diseñaba y analizaba, descubrí que algunos artículos tienen más de 8000 caracteres de longitud. Mi tabla tiene alguna columna como

PageID int,
PageTitleEnglish nvarchar(200),
PageTitleArabic nvarchar(200),
PageDescEnglish nvarchar(500),
PageDescArabic nvarchar(500),
PageBodyEnglish nvarchar(max)
PageBodyArabic nvarchar(max)

Si mantengo PageBody como nvarchar (4000), entonces estoy limitado a 4000 caracteres y si tengo que almacenar la versión en árabe, entonces necesito 16000 bytes (como árabe es Unicode y tomo 3 veces más espacio que ASCII).

Por lo tanto, solo me queda la opción de definir PageBody como nVarchar (max) , esto lo tendrá desde el punto de vista del rendimiento. Mi pregunta real es si algunos datos en la columna PageBody tienen menos de 4000 caracteres, ¿será MS SQL Store que los datos en la columna en línea o por separado en la base de datos?

También busqué esto en Google, pero no encontré ninguna respuesta relevante y cómo puedo mejorar el rendimiento en ese escenario.

Cualquier sugerencia de mejores prácticas para tal diseño de CMS multilingüe es bienvenida.

Necesito admitir solo dos idiomas árabe e inglés

Un nvarchar(max)valor se almacenará " en fila " si es lo suficientemente corto.

El comportamiento predeterminado se puede modificar mediante sp_tableoption , opción "tipos de valores grandes fuera de fila". No me molestaría El motor DB administrará esto de manera eficiente por sí mismo.

En cuanto al diseño, hay varias formas de hacerlo según su modelo:

• ¿Siempre tendrás inglés y árabe?
• ¿Se puede ser opcional? Si es así, ¿siempre será obligatorio?
• ¿Esperas más idiomas más tarde?

1. Tablas separadas

Es decir, puede dividir los idiomas separados en tablas diferentes.
Esto permite intercalaciones a nivel de tabla en lugar de a nivel de columna

Permite permitir más filas por página y más posibilidades de almacenamiento LOB en fila

PageParent

• ID de página int,
• PageOtherInfo ...

PageEnglish (nota varchar puede estar bien aquí)

• ID de página int,
• PageTitleEnglish varchar (200),
• PageDescEnglish varchar (500),
• PageBodyEnglish varchar (max)

Página Árabe

• ID de página int,
• Título de la página Nvarchar árabe (200),
• PageDescNvarchar árabe (500),
• PageBodyArabic nvarchar (max)

2. filas separadas

O tenga una columna languageID para admitir varios idiomas.
Esto tiene el inconveniente de que la clasificación se solucionará para todos los idiomas, lo que significa una clasificación / filtrado deficiente

PageParent

• ID de página int,
• PageOtherInfo ..

Página

• ID de página int,
• Código de lenguaje,
• Título de la página nvarchar (200),
• PageDesc nvarchar (500),
• PageBody nvarchar (max)

• MS SQL Server tiene un tamaño de página fijo de 8 KB.
• Una fila nunca se divide en varias páginas, pero varias filas pueden compartir una sola página.
• Sin embargo, nvarchar (max) y otros datos BLOB pueden almacenarse fuera de la fila / página.

Esto significa que para que todo encaje en una fila, la suma de todos los tamaños debe ser inferior a 8K. Si no es así, SQL Server almacenará los BLOB fuera de la fila / página.

¿Las cantidades de datos son tan grandes que esto realmente causa un problema de rendimiento?

Como otra opción, quizás podría cambiar la estructura de su base de datos para tener filas separadas para páginas en inglés y árabe, e incluir una columna de código de idioma en su lugar. Entonces no tendrá que ajustar tanto el texto en inglés como el árabe en la misma fila, y eso también tendría sentido al buscar datos, ya que probablemente no necesitaría buscar inglés y árabe al mismo tiempo.