nvarchar (max) vs NText

Quali sono i vantaggi e gli svantaggi dell'utilizzo dei tipi di dati nvarchar(max)vs. NTextin SQL Server? Non ho bisogno di compatibilità con le versioni precedenti, quindi va bene che nvarchar(max)non è supportato nelle versioni precedenti di SQL Server.

Modifica: a quanto pare la domanda vale anche per TEXTe IMAGEvs. varchar(max)e varbinary(max), per chi cerca successivamente quei tipi di dati.

I vantaggi sono che puoi usare funzioni come LENe LEFTon nvarchar(max)e non puoi farlo contro ntexte text. È anche più facile da lavorare nvarchar(max)rispetto a textdove dovevi usare WRITETEXTe UPDATETEXT.

Inoltre, text, ntext, ecc, vengono sconsigliata ( http://msdn.microsoft.com/en-us/library/ms187993.aspx )

VARCHAR(MAX)è abbastanza grande per accogliere il TEXTcampo. TEXT, NTEXTE IMAGEtipi di dati di SQL Server 2000 saranno deprecati nella versione futura di SQL Server, SQL Server 2005 fornisce la compatibilità all'indietro per i tipi di dati, ma si consiglia di utilizzare nuovi tipi di dati che sono VARCHAR(MAX), NVARCHAR(MAX)e VARBINARY(MAX).

ntextmemorizzerà sempre i suoi dati in una pagina di database separata, mentre nvarchar(max)proverà a memorizzare i dati all'interno del record del database stesso.

Quindi nvarchar(max)è un po 'più veloce (se hai testo più piccolo di 8 kB). Ho anche notato che le dimensioni del database aumenteranno leggermente più lentamente, anche questo è buono.

Go nvarchar(max).

nvarchar(max)è quello che vuoi usare. Il più grande vantaggio è che puoi usare tutte le funzioni di stringa T-SQL su questo tipo di dati. Questo non è possibile con ntext. Non sono a conoscenza di alcun reale svantaggio.

Apparentemente dovresti usare nvarchar(max):

MSDN

Il più grande svantaggio di Text(insieme a NTexte Image) è che verrà rimosso in una versione futura di SQL Server, come dalla documentazione . Ciò renderà effettivamente più difficile l'aggiornamento dello schema quando verrà rilasciata quella versione di SQL Server.

Volevo aggiungere la mia esperienza con la conversione. Avevo molti textcampi nell'antico codice Linq2SQL. Questo per consentire la ricostruzione ONLINE delletext colonne presenti negli indici .

In primo luogo ho conosciuto i vantaggi per anni, ma ho sempre pensato che la conversione avrebbe comportato alcune lunghe e spaventose query in cui SQL Server avrebbe dovuto ricostruire la tabella e copiare tutto, abbattendo i miei siti Web e aumentando il mio battito cardiaco.

Ero anche preoccupato che Linq2SQL potesse causare errori se stesse facendo una sorta di verifica del tipo di colonna.

Felice di segnalare, tuttavia, che i comandi ALTER sono tornati ISTANTANEAMENTE, quindi stanno sicuramente cambiando solo i metadati della tabella. Potrebbe esserci del lavoro offline in corso per riportare i dati <8000 caratteri nella tabella, ma il comando ALTER è stato istantaneo.

Ho eseguito quanto segue per trovare tutte le colonne che necessitano di conversione:

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

Questo mi ha dato un bel elenco di query, che ho appena selezionato e copiato in una nuova finestra. Come ho detto, correre questo è stato istantaneo.

Linq2SQL è piuttosto antico: utilizza un designer su cui trascinare le tabelle. La situazione potrebbe essere prima più complessa per il codice EF, ma non l'ho ancora affrontato.

Voglio aggiungere che è possibile utilizzare la clausola .WRITE per aggiornamenti parziali o completi e aggiunte ad alte prestazioni ai varchar(max)/nvarchar(max)tipi di dati.

Qui puoi trovare un esempio completo dell'uso della .WRITEclausola.