Il tipo di dati CHAR in SQL è obsoleto? Quando lo usi?

Question

Il titolo incornicia la domanda. Non ho usato CHAR da anni. Al momento, sto eseguendo il reverse engineering di un database che ha CHAR dappertutto, per chiavi primarie, codici, ecc. Che ne dici di una colonna CHAR (30)?

Modifica: Quindi l'opinione generale sembra essere quella CHAR se perfettamente soddisfacente per certe cose. Io, tuttavia, penso che sia possibile progettare uno schema di database che non ha bisogno di "queste certe cose", quindi non richiede stringhe a lunghezza fissa. Con bit, uniqueidentifier, varchar e tipi di testo, sembra che in uno schema ben normalizzato si ottenga una certa eleganza che non si ottiene quando si usano valori di stringa codificati. Pensare in termini fissi, senza offesa, sembra essere una reliquia dei giorni mainframe (ho imparato l'RPG II una volta sola). Credo che sia obsoleto, e non ho sentito argomentazioni convincenti da parte tua che rivendica il contrario.

Answer 1

Laddove la natura dei dati determina la lunghezza del campo, utilizzo CHAR. Altrimenti VARCHAR.

Answer 2

I CHAR sono ancora più veloci per l'elaborazione rispetto ai VARCHAR nel DBMS che conosco bene. Le loro dimensioni fisse consentono ottimizzazioni che non sono possibili con VARCHAR. Inoltre, i requisiti di archiviazione sono leggermente inferiori per CHARS poiché non è necessario memorizzare alcuna lunghezza, supponendo che la maggior parte delle righe abbia bisogno di compilare completamente o quasi completamente la colonna CHAR.

Questo è meno di un impatto (in termini di percentuale) con un CHAR (30) rispetto a un CHAR (4).

Per quanto riguarda l'utilizzo, tendo a usare CHARs quando:

• i campi saranno generalmente sempre vicino o sotto la loro lunghezza massima (codici degli stock, gli ID dei dipendenti, ecc); oppure
• le lunghezze sono brevi (meno di 10).

In qualsiasi altro luogo, utilizzo VARCHAR.

Answer 3

Uso char (n) per i codici, varchar (m) per le descrizioni. Char (n) sembra migliorare le prestazioni perché i dati non hanno bisogno di spostarsi quando la dimensione del contenuto cambia.

Answer 4

Uso CHAR quando la lunghezza del valore è fissa. Ad esempio stiamo generando un codice o qualcosa basato su un algoritmo che restituisce il codice con la specifica lunghezza fissa diciamo 13.

In caso contrario, ho trovato VARCHAR migliore. Un altro motivo per utilizzare VARCHAR è che quando si ripristina il valore nell'applicazione non è necessario ridimensionarlo. Nel caso di CHAR otterrete l'intera lunghezza della colonna, indipendentemente dal fatto che il valore lo stia riempiendo completamente o meno. Si riempirebbe di spazi e finirai per tagliare ogni valore, e dimenticando ciò porterebbe ad errori.

Answer 5

Char non è obsoleto, deve essere utilizzato solo se la lunghezza del campo non deve mai variare. Nel database medio, ci sarebbero pochissimi campi per lo più un qualche tipo di campo di codice come le abbreviazioni di stato che sono archiviate di 2 caratteri standard se si utilizzano i codici postali. Usare Char dove la lunghezza del file è varaible significa che ci sarà un sacco di operazioni di taglio in corso e questo è un lavoro extra, non necessario e il database dovrebbe essere refactored.

Answer 6

Per PostgreSQL, la documentazione indica che char() non ha alcun vantaggio nello spazio di archiviazione su varchar(); l'unica differenza è che è vuoto nella lunghezza specificata.

Detto questo, utilizzo ancora char(1) o char(3) per codici a un carattere oa tre caratteri. Penso che la chiarezza dovuta al tipo che specifica cosa dovrebbe contenere la colonna fornisca un valore, anche se non ci sono vantaggi di storage o prestazioni. E sì, in genere utilizzo i vincoli di controllo o anche i vincoli di chiave esterna. A parte questi casi, in genere utilizzo semplicemente text anziché utilizzare varchar(). Di nuovo, questo è informato dall'implementazione del database, che passa automaticamente dallo spazio di archiviazione non in linea se il valore è abbastanza grande, cosa che altre implementazioni di database non fanno.