Ci sono degli svantaggi nell'usare VARCHAR (MAX) in una tabella?

Question

Ecco la mia situazione.

Fondamentalmente, ho bisogno di una colonna in una tabella per contenere una lunghezza sconosciuta di caratteri. Ma ero curioso di sapere se in Sql Server i problemi di prestazioni potevano sorgere usando un VARCHAR (MAX) o NVARCHAR (MAX) in una colonna, come: 'Questa volta' ho solo bisogno di memorizzare 3 caratteri e il più delle volte ho solo bisogno di memorizzare 10 caratteri. Ma c'è una piccola possibilità che potrebbe essere fino a un paio di migliaia di caratteri in quella colonna, o forse anche a un milione, È imprevedibile. Ma posso garantire che non supererà il limite di 2 GB.

Ero curioso di sapere se ci sono problemi di prestazioni o modi migliori per risolvere questo problema, se disponibile.

Answer 1

Mi sembra che si preveda di utilizzare il tipo di dati varchar (MAX) per lo scopo previsto.

Quando i dati in un tipo di dati MAX superano 8 KB, viene utilizzata una pagina di overflow. SQL Server 2005 assegna automaticamente un indicatore di overflow alla pagina e sa come manipolare le righe di dati nello stesso modo in cui manipola altri tipi di dati.

Per ulteriori letture, controllare i libri in linea: char and varchar

Answer 2

No, varchar (max) si regola in base alle dimensioni della voce, quindi è il più efficiente se si prevede di utilizzare gli ingressi ampiamente varie dimensioni.

Answer 3

Ho appena visto l'articolo this l'altro giorno. Documenta un ritardo delle prestazioni relativamente minore per varchar (max) su una colonna varchar (n). Probabilmente non abbastanza per fare la differenza per te. Ma se lo fa, forse puoi usare una tabella separata per memorizzare quei pochi grandi blocchi di testo. Il tuo piccolo testo potrebbe rimanere nella tabella principale, ma potresti aggiungere un campo flag per dirti di guardare nella nuova tabella per i più grandi.

Answer 4

Non è possibile creare indici su varchar(max) (e nvarchar(max)) colonne (anche se possono essere inclusi in essi. Ma chi dovrebbe includere una colonna in un indice che potrebbe ottenere a 2GB ?!) quindi se volete per cercare questo valore , eseguirai una scansione ogni volta a meno che non utilizzi indici full-text. Inoltre, ricorda che qualsiasi progettista di report o designer di presentazioni (web o altro) deve presupporre che qualcuno possa inserire l'Enciclopedia in quella colonna e progettare attorno ad essa. Niente è peggio dell'udire "probabilmente gli utenti non faranno X". Se un utente può farlo, lo farà. Se un utente può inserire un tomo in una colonna, a un certo punto lo faranno. Se non dovrebbero mai, quindi IMO, ha più senso limitare la dimensione della colonna a un livello ragionevole e se un utente cerca di inserire più informazioni in quella colonna che è consentita, si otterrebbe una discussione sull'opportunità di inserire tale valore in quella colonna in primo luogo.

Answer 5

Ho visto alcuni problemi, in particolare con le funzioni scalari (ma in genere sono comunque orribili) che restituiscono varchar (MAX) e quindi non sono ri-cast. Ad esempio, supponiamo di avere una funzione speciale CleanString (somevarcharmax) restituisce varchar (max) e lo chiama su varchar (50) ma non CAST (CleanString (varchar10col) AS varchar (10)) - problemi di prestazioni brutti.

In genere, quando si dispone di colonne varchar (max) in una tabella, non si dovrebbero eseguire questi tipi di operazioni in massa, quindi direi se lo si utilizza correttamente per le esigenze dei dati nella tabella , allora va bene.

Answer 6

Crystal Reports 12 (e altre versioni, per quanto ne so) non gestisce varchar (max) correttamente e lo interpreta come varchar (255) che porta a dati troncati nei report.

Quindi, se si utilizza Crystal Reports, questo è uno svantaggio per varchar (max).O uno svantaggio nell'usare Crystal, per essere precisi.

See:
http://www.crystalreportsbook.com/Forum/forum_posts.asp?TID=5843&PID=17503
http://michaeltbeeitprof.blogspot.com/2010/05/crystal-xi-and-varcharmax-aka-memo.html