Ci sono degli svantaggi nell'usare sempre nvarchar (MAX)?

In SQL Server 2005 ci sono degli svantaggi nel rendere tutti i campi di caratteri nvarchar (MAX) anziché specificare esplicitamente una lunghezza, ad esempio nvarchar (255)? (A parte quello ovvio che non sei in grado di limitare la lunghezza del campo a livello di database)

La stessa domanda è stata posta sui forum MSDN:

• Varchar (max) vs Varchar (255)

Dal post originale (molte più informazioni lì):

Quando si memorizzano i dati in una colonna VARCHAR (N), i valori vengono archiviati fisicamente allo stesso modo. Ma quando lo memorizzi in una colonna VARCHAR (MAX), dietro lo schermo i dati vengono gestiti come valore TEXT. Quindi è necessaria un'ulteriore elaborazione quando si ha a che fare con un valore VARCHAR (MAX). (solo se la dimensione supera 8000)

VARCHAR (MAX) o NVARCHAR (MAX) è considerato un "tipo di valore elevato". I tipi di valore elevato vengono generalmente archiviati "fuori riga". Significa che la riga di dati avrà un puntatore a un'altra posizione in cui è memorizzato il "valore grande" ...

È una domanda giusta e lo ha affermato a parte l'ovvio ...

Gli svantaggi potrebbero includere:

Implicazioni sulle prestazioni Lo Strumento per ottimizzare le query utilizza le dimensioni del campo per determinare il piano di esecuzione più efficace

"1. L'allocazione dello spazio negli spazi estesi e nelle pagine del database è flessibile. Pertanto, quando si aggiungono informazioni al campo mediante l'aggiornamento, il database dovrebbe creare un puntatore se i nuovi dati sono più lunghi di quelli precedentemente inseriti. In questo modo i file del database diventare frammentato = prestazioni inferiori in quasi tutto, dall'indice all'eliminazione, dall'aggiornamento e dagli inserimenti. " http://sqlblogcasts.com/blogs/simons/archive/2006/02/28/Why-use-anything-but-varchar_2800_max_2900_.aspx

Implicazioni sull'integrazione - difficile per altri sistemi sapere come integrarsi con il database Crescita imprevedibile dei dati Possibili problemi di sicurezza, ad esempio, è possibile che si blocchi un sistema occupando tutto lo spazio su disco

C'è un buon articolo qui: http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1098157,00.html

Sulla base del link fornito nella risposta accettata sembra che:

1. 100 caratteri memorizzati in un nvarchar(MAX)campo verranno archiviati in modo diverso da 100 caratteri in un nvarchar(100)campo: i dati verranno archiviati in linea e non si avrà il sovraccarico di leggere e scrivere i dati "fuori riga". Quindi non preoccuparti.

2. Se la dimensione è maggiore di 4000 i dati verrebbero archiviati automaticamente "fuori riga", che è quello che vorresti. Quindi non preoccuparti neanche lì.

Però...

3. Non è possibile creare un indice su un nvarchar(MAX) colonna. È possibile utilizzare l'indicizzazione full-text, ma non è possibile creare un indice sulla colonna per migliorare le prestazioni della query. Per me, questo sigilla l'affare ... è un netto svantaggio usare sempre nvarchar (MAX).

Conclusione:

Se si desidera una sorta di "lunghezza di stringa universale" in tutto il database, che può essere indicizzata e che non sprecherà spazio e tempo di accesso, è possibile utilizzare nvarchar(4000).

A volte vuoi che il tipo di dati imponga un certo senso sui dati in esso contenuti.

Supponiamo ad esempio di avere una colonna che in realtà non dovrebbe essere più lunga, per esempio, di 20 caratteri. Se definisci quella colonna come VARCHAR (MAX), alcune applicazioni non autorizzate potrebbero inserire una lunga stringa in essa e non lo sapresti mai, o avresti modo di impedirlo.

La prossima volta che l'applicazione utilizzerà quella stringa, supponendo che la lunghezza della stringa sia modesta e ragionevole per il dominio che rappresenta, si verificherà un risultato imprevedibile e confuso.

Ho controllato alcuni articoli e ho trovato utili script di test da questo: http://www.sqlservercentral.com/Forums/Topic1480639-1292-1.aspx Quindi l'ho modificato per confrontarlo tra NVARCHAR (10) vs NVARCHAR (4000) vs NVARCHAR (MAX ) e non trovo la differenza di velocità quando si utilizzano numeri specifici ma quando si utilizza MAX. Puoi testare da solo. Spero che questo aiuto.

SET NOCOUNT ON;

--===== Test Variable Assignment 1,000,000 times using NVARCHAR(10)
DECLARE @SomeString NVARCHAR(10),
        @StartTime DATETIME;
--=====         
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='10', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(4000)
DECLARE @SomeString NVARCHAR(4000),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='4000', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(MAX)
DECLARE @SomeString NVARCHAR(MAX),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='MAX', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO

Pensalo come un altro livello di sicurezza. È possibile progettare la tabella senza relazioni con chiavi esterne - perfettamente valida - e garantire l'esistenza di entità associate interamente a livello aziendale. Tuttavia, le chiavi esterne sono considerate buone prassi di progettazione perché aggiungono un altro livello di vincolo nel caso in cui qualcosa si incasini sul livello aziendale. Lo stesso vale per la limitazione delle dimensioni del campo e per non utilizzare varchar MAX.

Un motivo per NON utilizzare i campi max o text è che non è possibile eseguire ricostruzioni di indici online, ad esempio REVISIONE CON ONLINE = ON anche con SQL Server Enterprise Edition.

L'unico problema che ho riscontrato è stato che sviluppiamo le nostre applicazioni su SQL Server 2005 e, in un'istanza, dobbiamo supportare SQL Server 2000. Ho appena imparato, nel modo più duro che a SQL Server 2000 non piace l'opzione MAX per varchar o nvarchar.

Una cattiva idea quando sai che il campo sarà compreso tra 5 e 10 caratteri, ad esempio. Penso che userei max solo se non fossi sicuro di quale lunghezza sarebbe. Ad esempio un numero di telefono non sarebbe mai superiore a un certo numero di caratteri.

Puoi onestamente dire che non sei così sicuro dei requisiti di lunghezza approssimativa per ogni campo della tua tabella?

Capisco però: ci sono alcuni campi che sicuramente prenderei in considerazione usando varchar (max).

È interessante notare che i documenti MSDN lo riassumono abbastanza bene:

Utilizzare varchar quando le dimensioni delle voci di dati della colonna variano considerevolmente. Utilizzare varchar (max) quando le dimensioni delle voci di dati della colonna variano considerevolmente e la dimensione potrebbe superare gli 8.000 byte.

C'è un'interessante discussione sull'argomento qui .

Il compito del database è archiviare i dati in modo che possano essere utilizzati dall'azienda. Parte del rendere tali dati utili è garantire che siano significativi. Consentire a qualcuno di inserire un numero illimitato di caratteri per il proprio nome non garantisce dati significativi.

La creazione di questi vincoli nel livello aziendale è una buona idea, ma ciò non garantisce che il database rimanga intatto. L'unico modo per garantire che le regole sui dati non vengano violate è applicarle al livello più basso possibile nel database.

Un problema è che se devi lavorare con più versioni di SQL Server, il MAX non funzionerà sempre. Quindi, se stai lavorando con DB legacy o qualsiasi altra situazione che coinvolge più versioni, è meglio stare molto attenti.

Come sottolineato sopra, si tratta principalmente di un compromesso tra archiviazione e prestazioni. Almeno nella maggior parte dei casi.

Tuttavia, c'è almeno un altro fattore che dovrebbe essere considerato quando si sceglie n / varchar (Max) su n / varchar (n). I dati verranno indicizzati (come, per esempio, un cognome)? Poiché la definizione MAX è considerata un LOB, tutto ciò che è definito MAX non è disponibile per l'indicizzazione. e senza un indice, qualsiasi ricerca che coinvolga i dati come predicato in una clausola WHERE verrà forzata in una scansione della tabella completa, che è la peggiore prestazione che puoi ottenere per le ricerche di dati.

1) Il server SQL dovrà utilizzare più risorse (memoria allocata e tempo della CPU) quando ha a che fare con nvarchar (max) vs nvarchar (n) dove n è un numero specifico per il campo.

2) Cosa significa questo per quanto riguarda le prestazioni?

Su SQL Server 2005, ho eseguito una query su 13.000 righe di dati da una tabella con 15 colonne nvarchar (max). Ho cronometrato ripetutamente le query e poi ho cambiato le colonne in nvarchar (255) o meno.

Le query precedenti all'ottimizzazione sono state in media di 2,0858 secondi. Le query dopo la modifica sono state restituite in media 1,90 secondi. Sono stati circa 184 millisecondi di miglioramento rispetto alla query select * di base. Questo è un miglioramento dell'8,8%.

3) I miei risultati sono in concomitanza con alcuni altri articoli che indicavano una differenza di prestazioni. A seconda del database e della query, la percentuale di miglioramento può variare. Se non hai molti utenti simultanei o molti record, la differenza di prestazioni non sarà un problema per te. Tuttavia, la differenza di prestazioni aumenterà all'aumentare del numero di record e degli utenti simultanei.

Ho avuto un udf che ha riempito le stringhe e messo l'output su varchar (max). Se questo è stato usato direttamente invece di tornare alle dimensioni appropriate per la colonna da regolare, le prestazioni erano molto scarse. Ho finito per mettere udf ad una lunghezza arbitraria con una grande nota invece di fare affidamento su tutti i chiamanti di udf per ripetere il cast della stringa su una dimensione più piccola.

supporto del sistema legacy. Se si dispone di un sistema che utilizza i dati e si prevede che abbia una certa lunghezza, il database è un buon posto per imporre la lunghezza. Questo non è l'ideale ma i sistemi legacy a volte non sono l'ideale. = P

Se tutti i dati in una riga (per tutte le colonne) non prenderebbero mai ragionevolmente 8000 o meno caratteri, il design a livello di dati dovrebbe imporlo.

Il motore di database è molto più efficiente mantenendo tutto fuori dall'archiviazione BLOB. Più piccolo è possibile limitare una riga, meglio è. Più righe puoi stipare in una pagina, meglio è. Il database funziona meglio quando deve accedere a un minor numero di pagine.

I miei test hanno dimostrato che ci sono differenze nella selezione.

CREATE TABLE t4000 (a NVARCHAR(4000) NULL);

CREATE TABLE tmax (a NVARCHAR(MAX) NULL);

DECLARE @abc4 NVARCHAR(4000) = N'ABC';

INSERT INTO t4000
SELECT TOP 1000000 @abc4
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

DECLARE @abc NVARCHAR(MAX) = N'ABC';

INSERT INTO tmax
SELECT TOP 1000000 @abc
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

SET STATISTICS TIME ON;
SET STATISTICS IO ON;

SELECT * FROM dbo.t4000;
SELECT * FROM dbo.tmax;

Link interessante: Perché usare un VARCHAR quando puoi usare TEXT?

Riguarda PostgreSQL e MySQL, quindi l'analisi delle prestazioni è diversa, ma la logica di "explicitness" è ancora valida: perché forzarti a preoccuparti sempre di qualcosa che è rilevante una piccola percentuale delle volte? Se salvassi un indirizzo email in una variabile, utilizzeresti una "stringa" e non una "stringa limitata a 80 caratteri".

Lo svantaggio principale che posso vedere è che diciamo che hai questo:

Quale ti dà il maggior numero di informazioni sui dati necessari per l'interfaccia utente?

Questo

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](MAX) NULL,
                [CompanyName] [nvarchar](MAX) NOT NULL,
                [FirstName] [nvarchar](MAX) NOT NULL,
                [LastName] [nvarchar](MAX) NOT NULL,
                [ADDRESS] [nvarchar](MAX) NOT NULL,
                [CITY] [nvarchar](MAX) NOT NULL,
                [County] [nvarchar](MAX) NOT NULL,
                [STATE] [nvarchar](MAX) NOT NULL,
                [ZIP] [nvarchar](MAX) NOT NULL,
                [PHONE] [nvarchar](MAX) NOT NULL,
                [COUNTRY] [nvarchar](MAX) NOT NULL,
                [NPA] [nvarchar](MAX) NULL,
                [NXX] [nvarchar](MAX) NULL,
                [XXXX] [nvarchar](MAX) NULL,
                [CurrentRecord] [nvarchar](MAX) NULL,
                [TotalCount] [nvarchar](MAX) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

O questo?

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](50) NULL,
                [CompanyName] [nvarchar](50) NOT NULL,
                [FirstName] [nvarchar](50) NOT NULL,
                [LastName] [nvarchar](50) NOT NULL,
                [ADDRESS] [nvarchar](50) NOT NULL,
                [CITY] [nvarchar](50) NOT NULL,
                [County] [nvarchar](50) NOT NULL,
                [STATE] [nvarchar](2) NOT NULL,
                [ZIP] [nvarchar](16) NOT NULL,
                [PHONE] [nvarchar](18) NOT NULL,
                [COUNTRY] [nvarchar](50) NOT NULL,
                [NPA] [nvarchar](3) NULL,
                [NXX] [nvarchar](3) NULL,
                [XXXX] [nvarchar](4) NULL,
                [CurrentRecord] [nvarchar](50) NULL,
                [TotalCount] [nvarchar](50) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

Uno svantaggio è che si progetterà attorno a una variabile imprevedibile e probabilmente si ignorerà invece di sfruttare la struttura interna dei dati di SQL Server, costituita progressivamente da Row (s), Page (s) ed Extent (s).

Il che mi fa pensare all'allineamento della struttura dei dati in C e che essere consapevoli dell'allineamento è generalmente considerato una buona cosa (TM). Idea simile, contesto diverso.

Pagina MSDN per pagine ed estensioni

Pagina MSDN per i dati di overflow delle righe

in primo luogo ho pensato a questo, ma poi ho pensato di nuovo. Ci sono implicazioni sulle prestazioni, ma allo stesso modo serve come forma di documentazione per avere un'idea delle dimensioni dei campi. E si applica quando quel database si trova in un ecosistema più grande. Secondo me la chiave deve essere permissiva ma solo entro limiti ragionevoli.

ok, ecco i miei sentimenti semplicemente sulla questione del business e della logica del livello dati. Dipende, se il tuo DB è una risorsa condivisa tra sistemi che condividono la logica di business, allora ovviamente sembra un luogo naturale per applicare tale logica, ma non è il modo MIGLIORE per farlo, il modo MIGLIORE è fornire un'API, questo consente l'interazione da testare e mantiene la logica aziendale a cui appartiene, mantiene i sistemi disaccoppiati, mantiene i livelli all'interno di un sistema disaccoppiato. Se tuttavia si suppone che il tuo database stia servendo una sola applicazione, allora lascia che AGILE pensi, che cosa è vero adesso? design per ora. Se e quando è necessario tale accesso, fornire un'API a tali dati.

ovviamente, però, questo è l'ideale, se stai lavorando con un sistema esistente la probabilità è che dovrai farlo diversamente, almeno nel breve periodo.

Ciò causerà un problema di prestazioni, sebbene non possa mai causare problemi reali se il database è piccolo. Ogni record occuperà più spazio sul disco rigido e il database dovrà leggere più settori del disco se si cercano più record contemporaneamente. Ad esempio, un piccolo record potrebbe adattarsi a 50 di un settore e un record di grandi dimensioni potrebbe adattarsi a 5. Dovresti leggere 10 volte più dati dal disco usando il record di grandi dimensioni.

Renderà più difficile la progettazione dello schermo poiché non sarai più in grado di prevedere la larghezza dei controlli.