Tipo di testo SQL Server e tipo di dati varchar [chiuso]


287

Ho dati di caratteri di lunghezza variabile e voglio archiviarli nel database di SQL Server (2005). Voglio imparare alcune best practice su come scegliere il tipo di TEXT SQL o come scegliere il tipo VARCHAR SQL, i pro ei contro in termini di prestazioni / footprint / funzione.


17
Se Google ti ha inviato qui: la pagina Tipi di dati SQL MSDN può essere d'aiuto.
Jeroen,

Risposte:


212

Se si utilizza SQL Server 2005 o versione successiva, utilizzare varchar(MAX). Il texttipo di dati è obsoleto e non deve essere utilizzato per nuovi lavori di sviluppo. Dai documenti :

Importante

ntext, texte imagei tipi di dati verranno rimossi in una versione futura di Microsoft SQL Server. Evitare di utilizzare questi tipi di dati nel nuovo lavoro di sviluppo e pianificare di modificare le applicazioni che attualmente li utilizzano. Utilizzare invece nvarchar (max) , varchar (max) e varbinary (max) .


3
Grazie Mladen, sono sorpreso di vedere che TEXT è deprecato. Hai documenti ufficiali che lo menzionano?
George2,

1
Anche se questo non è "ufficiale", copre le basi. Il testo è in effetti deprezzato e inoltre non supporta tutto ciò che fa varchar (max), come la possibilità di cercare e indicizzare. blog.sqlauthority.com/2007/05/26/…
achinda99

32
questo è tanto ufficiale quanto arriva :) msdn.microsoft.com/en-us/library/ms187993.aspx
Mladen Prajdic,

1
Cool achinda99 e Mladen Prajdic! Quello che hai fornito è quello che sto cercando. :-) Ancora una domanda, come possiamo scegliere se utilizzare VARCHAR o VARCHAR (MAX) in diverse situazioni?
George2,

1
Le informazioni ufficiali di MS su di esso sono obsolete: msdn.microsoft.com/en-us/library/ms187993%28v=sql.90%29.aspx
Fanda

283

TEXTviene utilizzato per grandi quantità di dati stringa. Se la lunghezza del campo supera una certa soglia, il testo viene archiviato fuori riga.

VARCHARviene sempre archiviato in una riga e ha un limite di 8000 caratteri. Se si tenta di creare un VARCHAR(x), dove x> 8000 , viene visualizzato un errore:

Server: messaggio 131, livello 15, stato 3, riga 1

La dimensione () assegnata al tipo 'varchar' supera il massimo consentito per qualsiasi tipo di dati (8000)

Questi limiti di lunghezza non riguardano VARCHAR(MAX)in SQL Server 2005 , che possono essere tenuti fuori della fila, proprio come TEXT.

Nota che qui MAXnon è un tipo di costante, VARCHARe VARCHAR(MAX)sono tipi molto diversi, quest'ultimo essendo molto vicino TEXT.

Nelle versioni precedenti di SQL Server non era possibile accedere TEXTdirettamente a, è possibile ottenere solo un TEXTPTRe utilizzarlo READTEXTe WRITETEXTfunzioni.

In SQL Server 2005 è possibile accedere direttamente alle TEXTcolonne (sebbene sia ancora necessario un cast esplicito VARCHARper assegnare un valore per esse).

TEXT è buono:

  • Se è necessario memorizzare testi di grandi dimensioni nel database
  • Se non si cerca il valore della colonna
  • Se selezioni questa colonna raramente e non ti iscrivi su di essa.

VARCHAR è buono:

  • Se conservi piccole stringhe
  • Se cerchi il valore della stringa
  • Se lo selezioni sempre o lo usi nei join.

Con la selezione qui intendo procedere all'emissione di query che restituiscono il valore della colonna.

Con la ricerca qui intendo il rilascio di domande il cui risultato dipende dal valore della TEXTo VARCHARcolonna. Ciò include l'utilizzo in qualsiasi JOINo WHEREcondizione.

Poiché il file TEXTè archiviato fuori riga, le query che non riguardano la TEXTcolonna sono in genere più veloci.

Alcuni esempi di ciò che TEXTè buono per:

  • Commenti sul blog
  • Pagine Wiki
  • Codice sorgente

Alcuni esempi di ciò che VARCHARè buono per:

  • Nomi utente
  • Titoli di pagina
  • I nomi dei file

Come regola generale, se hai mai bisogno del tuo valore di testo per superare i 200 caratteri E non usare join su questa colonna, usa TEXT.

Altrimenti usa VARCHAR.

PS Lo stesso vale per UNICODEabilitato NTEXTe NVARCHARpure, che dovresti usare per gli esempi sopra.

PPS Lo stesso vale per VARCHAR(MAX)e NVARCHAR(MAX)che SQL Server 2005+ utilizza al posto di TEXTe NTEXT. Dovrai abilitarli large value types out of rowcon sp_tableoptionse vuoi che siano sempre archiviati fuori dalla riga.

Come accennato in precedenza e qui , TEXTsarà deprecato nelle versioni future:

L' text in rowopzione verrà rimossa in una versione futura di SQL Server . Evita di utilizzare questa opzione nel nuovo lavoro di sviluppo e pianifica di modificare le applicazioni che attualmente utilizzano text in row. Si consiglia di memorizzare grandi quantità di dati utilizzando i varchar(max), nvarchar(max)o varbinary(max)tipi di dati. Per controllare il comportamento in riga e fuori riga di questi tipi di dati, utilizzare l' large value types out of rowopzione


2
1. "Se non cerchi il valore della colonna", potresti mostrarmi cosa intendi per "ricerca"? Vuoi dire selezionare questa colonna, ordinare questa colonna, COME questa colonna o usare qualche funzione di manipolazione delle stringhe su questa colonna?
George2,

2
2. "VARCHAR è sempre memorizzato nella riga e ha un limite di 8000 caratteri." - scusa non sono d'accordo con te. VARCHAR potrebbe essere più lungo di 8000 e se più lungo di 8000, VARCHAR verrà archiviato se non in colonne. Qualche commento?
George2,

1
3. Mladen Prajdic menzionato in questa discussione, il tipo TEXT è obsoleto, ma non trovo alcun documento che lo copra. Hai qualche documento su questo?
George2,

2
Fantastico Quassnoi! Sei così conoscibile! :-) Un'altra domanda - "Questo ovviamente non riguarda VARCHAR (MAX), che è come per SQL SERVER 2005 un sinonimo di TEXT." "Questo" intendi cosa?
George2,

"Questo ovviamente non riguarda VARCHAR (MAX), che è come per SQL SERVER 2005 un sinonimo di TEXT." - hai qualche documento che dice che TEXT è lo stesso di VARCHAR in SQL Server 2005? Ho fatto qualche ricerca ma non riesco a trovare documenti ufficiali. :-)
George2,

41

In SQL Server 2005 sono stati introdotti nuovi tipi di dati: varchar(max)e nvarchar(max) presentano i vantaggi del vecchio tipo di testo: possono contenere da 2 GB di dati, ma presentano anche la maggior parte dei vantaggi di varchare nvarchar. Tra questi vantaggi vi è la possibilità di utilizzare funzioni di manipolazione delle stringhe come substring ().

Inoltre, varchar (max) viene archiviato nello spazio (disco / memoria) della tabella mentre la dimensione è inferiore a 8 KB. Solo quando si inseriscono più dati nel campo, questi vengono archiviati dallo spazio della tabella. I dati memorizzati nello spazio della tabella vengono (di solito) recuperati più rapidamente.

In breve, non usare mai il testo, poiché esiste un'alternativa migliore: (n) varchar (max). E usa varchar (max) solo quando un varchar normale non è abbastanza grande, cioè se ti aspetti che la stringa che stai per memorizzare superi 8000 caratteri.

Come è stato notato, è possibile utilizzare SUBSTRING sul tipo di dati TEXT, ma solo finché i campi TEXT contengono meno di 8000 caratteri.


1
Grazie Edoode, hai risposto abbastanza bene quanto è buono VARCHAR, ma hai commenti o idee su quando usare VARCHAR e quando usare TEXT? La mia domanda riguarda la scelta di 1 numero da 2. :-)
George2,

1
In realtà, in MS SQL Server 2005 è possibile utilizzare SUBSTRING e altre funzioni anche nelle colonne TEXT.
Quassnoi,

1
Grazie Quassnoi! Sembra che TEXT sia deprecato. Ancora una domanda, come possiamo scegliere se utilizzare VARCHAR o VARCHAR (MAX) in diverse situazioni?
George2,

1
Usa varchar (max) solo quando un varchar normale non è abbastanza grande (8Kb dovrebbe essere sufficiente per tutti;)
edosoft,

7

Ci sono stati alcuni cambiamenti importanti nel ms 2008 -> Potrebbe valere la pena considerare il seguente articolo quando si prendono decisioni sul tipo di dati da usare. http://msdn.microsoft.com/en-us/library/ms143432.aspx

Byte per

  1. varchar (max), varbinary (max), xml, text o image column 2 ^ 31-1 2 ^ 31-1
  2. nvarchar (max) colonna 2 ^ 30-1 2 ^ 30-1

3
I cambiamenti? Queste capacità non sono cambiate da quando sono stati introdotti i nuovi tipi di dati.
Martin Smith,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.