campi varchar: la potenza di altri due è più efficiente?

Question

È più efficiente utilizzare un campo varchar di dimensioni pari a due o un altro? Sto pensando no, perché per SQL Server il valore predefinito è 50.

Tuttavia, ho sentito (ma non ho mai confermato) che i campi di dimensionamento come potenza di 2 sono più efficienti perché equivalgono anche a byte e computer processo in bit & byte.

Quindi, un campo dichiarato come varchar(32) o varchar(64) ha un vantaggio reale rispetto a varchar(50)?

Answer 1

No.

In alcuni altri usi, ci sono alcuni vantaggi di utilizzare le strutture con una potenza di due dimensioni, soprattutto perché è possibile montare una bella (potenza di due) certo numero di questi all'interno di un altro potere- struttura a due dimensioni. Ma questo non si applica a un campo DB.

L'unico power-of-two-sizing relativo a VARCHAR riguarda il tipo esatto di varchar (o TEXT/BLOB in alcuni dialetti SQL): se è inferiore a 256, può utilizzare un singolo byte per indicare la lunghezza. se è inferiore a 65536 (64 KB), bastano due byte, tre byte funzionano fino a 16777216 (16 MB), quattro byte passano a 4294967296 (4 GB).

Inoltre, si può sostenere che VARCHAR(50) è altrettanto costoso di VARCHAR(255), poiché entrambi necessitano n + 1 byte di spazio.

Certo che è prima di pensare di Unicode ...

Answer 2

Ho sempre pensato che le persone scelgano il potere di due per i campi varchar perché siamo geek e questo è quello che facciamo. Almeno questo è quello che ho sempre fatto.

Answer 3

Dipende dall'implementazione specifica del database, ma non me lo aspetterei. Non sta eseguendo calcoli sul numero di caratteri, generalmente, quindi non dovrebbe influenzare le prestazioni - solo lo spazio.

Answer 4

L'unico vantaggio tangibile che si otterrà dall'utilizzo di determinate lunghezze massime è lo spazio di archiviazione richiesto per VARCHAR. Una lunghezza massima su 255 richiederebbe un byte extra per memorizzare la lunghezza del valore in ogni riga (e un extra di 2 byte per lunghezze di 256^2 o superiori e così via).

Answer 5

Per SQL in generale? No. Per una specifica implementazione, forse.

Ciò che è più efficiente non è determinato da una specifica (SQL è solo una specifica), ma come viene implementato in un determinato DBMS.