in che modo nvarchar (max) memorizzerà i dati nel database sarà veloce se alcuni dati sono inferiori a 4000 caratteri?

Devo sviluppare un CMS che supporterà due lingue inglese, arabo. Questo CMS sarà una sorta di sito di pubblicazione di articoli. Durante la progettazione e l'analisi ho scoperto che alcuni articoli sono lunghi più di 8000 caratteri. La mia tabella ha una colonna come

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

Se tengo PageBody come nvarchar (4000), allora ho un limite di 4000 caratteri e se devo memorizzare la versione araba, allora ho bisogno di 16000 byte (poiché l'arabo è Unicode e occupa 3 volte più spazio di ASCII).

Quindi sono rimasto solo con l'opzione di definire PageBody come nVarchar (max) , questo avrà un aspetto negativo dal punto di vista delle prestazioni. La mia vera domanda è se alcuni dati nella colonna PageBody sono meno di 4000 caratteri che verranno archiviati da MS SQL Store rispetto ai dati nella colonna incorporata o separatamente nel database.

L'ho cercato anche su Google ma non ho trovato alcuna risposta pertinente e come posso migliorare le prestazioni in tale scenario.

Qualsiasi suggerimento per le migliori pratiche per tale progettazione di CMS multilingue è il benvenuto.

Devo supportare solo due lingue arabo e inglese

Un nvarchar(max)valore verrà memorizzato " in-row " se è abbastanza corto.

Il comportamento predefinito può essere modificato utilizzando sp_tableoption , opzione "tipi di valori grandi fuori riga". Non mi preoccuperei. Il motore DB gestirà questo in modo efficiente da solo.

Per quanto riguarda il design, ci sono diversi modi per farlo in base al tuo modello:

• Avrai sempre inglese e arabo?
• Si può essere facoltativi? Se è così, uno sarà sempre obbligatorio?
• Ti aspetti più lingue dopo?

1. Tabelle separate

Cioè, puoi dividere le lingue separate in diverse tabelle.
Ciò consente regole di confronto a livello di tabella anziché a livello di colonna

Permette più righe per pagina e maggiori possibilità di archiviazione LOB in fila

PageParent

• PageID int,
• PageOtherInfo ...

PageEnglish (nota varchar potrebbe essere OK qui)

• PageID int,
• PageTitleEnglish varchar (200),
• PageDescEnglish varchar (500),
• PageBodyEnglish varchar (max)

PageArabic

• PageID int,
• PageTitleArabic nvarchar (200),
• PageDescArabic nvarchar (500),
• PageBodyArabic nvarchar (max)

2. Separare le file

O avere una colonna languageID per supportare diverse lingue.
Ciò ha lo svantaggio che le regole di confronto verranno riparate per tutte le lingue, il che significa un ordinamento / filtro scadente

PageParent

• PageID int,
• PageOtherInfo ..

Pagina

• PageID int,
• LanguageCode,
• PageTitle nvarchar (200),
• PageDesc nvarchar (500),
• PageBody nvarchar (max)

• MS SQL Server ha una dimensione di pagina fissa di 8 KB.
• Una riga non viene mai suddivisa su più pagine, ma più righe possono condividere una singola pagina.
• nvarchar (max) e altri dati BLOB possono tuttavia essere memorizzati al di fuori della riga / pagina.

Ciò significa che affinché tutto si inserisca in una riga, la somma di tutte le dimensioni deve essere inferiore a 8 KB. In caso contrario, SQL Server memorizzerà i BLOB all'esterno della riga / pagina.

Le quantità di dati sono così grandi da causare davvero un problema di prestazioni?

Come altra opzione, potresti forse modificare la tua struttura di database in modo da avere righe separate per pagine inglesi e arabe e includere invece una colonna di codice lingua. Quindi non dovrai adattare sia il testo inglese che quello arabo nella stessa riga, e ciò avrebbe senso anche quando recuperi i dati, poiché probabilmente non avrai bisogno di recuperare inglese e arabo allo stesso tempo.