Qualsiasi insidia nascosta che modifica una colonna da varchar (8000) a varchar (max)?

Question

Ho molto (oltre un migliaio di posti) di codice legacy T-SQL che rende solo INSERT s in una colonna varchar(8000) in una tabella di utilità. Le nostre esigenze sono cambiate e ora la colonna deve essere in grado di gestire valori più grandi. Di conseguenza ho bisogno di fare quella colonna varchar(max). Questa è solo una semplice colonna di dati dove non ci sono ricerche preformate su di essa, nessun indice su di essa, solo una procedura la legge, è INSERT e dimentica per l'applicazione (quasi come una voce di registro).

Pianifico di apportare modifiche solo in alcuni punti che generano effettivamente i dati più grandi e nella singola stored procedure che elabora questa colonna.

• C'è qualche insidia nascosta che modifica una colonna da varchar(8000) a varchar(max)?
• Lavoreranno tutte le T-SQL funzioni stringa stessa, LEN(), RTRIM(), SUBSTRING(), ecc
• Qualcuno riesce a immaginare alcuna ragione per cui avrei dovuto apportare modifiche al codice che pensa la colonna è ancora varchar(8000)?

Answer 1

• Tutti i tipi MAX hanno una piccola penalizzazione delle prestazioni, vedere Performance comparison of varchar(max) vs. varchar(N).
• Se la manutenzione include operazioni online (ricostruzione indice in linea), si perderà la possibilità di eseguirle. Online operations are not supported for tables with BLOB columns:

  • devono essere creati gli indici cluster, ricostruito, o cadere offline quando la tabella sottostante contiene grandi oggetti (LOB) i tipi di dati: immagine, ntext, text, varchar (max), nvarchar (max) , varbinary (max) e xml.
  • Gli indici non cluster non univoci possono essere creati online quando la tabella contiene tipi di dati LOB ma nessuna di queste colonne viene utilizzata nella definizione dell'indice come colonne chiave o non chiave (incluse). Gli indici non cluster definiti con le colonne del tipo di dati LOB devono essere creati o ricostruiti offline.

La pena di performance è davvero piccolo, quindi non mi preoccuperei. La perdita di capacità di fare ricostruzioni online può essere problematica per le tabelle di operazioni veramente hot must-be-online. A meno che le operazioni online non siano un must, voterei per farlo e cambiarlo in MAX.

Answer 2

Se davvero non hai bisogno di indici ed è una colonna grande, dovresti stare bene. Varchar (max) sembra essere esattamente ciò di cui hai bisogno e avrai meno problemi con il codice esistente di quanto faresti se avessi usato il testo.

Assicurarsi di verificare eventuali aggiornamenti in cui il testo viene aggiunto al testo esistente. Dovrebbe funzionare usando una concatenazione regolare, ma vorrei essere in grado di dimostrarlo.

Answer 3

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.

Vedi:
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