PostgreSQL: Differenza tra testo e varchar (carattere variabile)

Qual è la differenza tra il texttipo di dati e i tipi di dati character varying( varchar)?

Secondo la documentazione

Se si utilizza la variazione di carattere senza identificatore di lunghezza, il tipo accetta stringhe di qualsiasi dimensione. Quest'ultima è un'estensione PostgreSQL.

e

Inoltre, PostgreSQL fornisce il tipo di testo, che memorizza stringhe di qualsiasi lunghezza. Sebbene il testo del tipo non sia nello standard SQL, anche molti altri sistemi di gestione del database SQL lo hanno.

Quindi qual è la differenza?

Non c'è differenza, sotto il cofano è tutto varlena( array di lunghezza variabile ).

Controlla questo articolo da Depesz: http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/

Un paio di punti salienti:

Per riassumere tutto:

• char (n) - occupa troppo spazio quando si ha a che fare con valori più brevi di n(li riempie in n) e può portare a sottili errori a causa dell'aggiunta di spazi finali, inoltre è problematico modificare il limite
• varchar (n) - è problematico modificare il limite nell'ambiente live (richiede un blocco esclusivo durante la modifica della tabella)
• varchar: proprio come il testo
• testo - per me un vincitore - su (n) tipi di dati perché manca di problemi e su varchar - perché ha un nome distinto

L'articolo esegue test dettagliati per dimostrare che le prestazioni degli inserti e delle selezioni per tutti e 4 i tipi di dati sono simili. Dà anche un'occhiata dettagliata a modi alternativi per limitare la lunghezza quando necessario. I vincoli o i domini basati su funzioni offrono il vantaggio di un aumento istantaneo del vincolo di lunghezza e sulla base del fatto che la riduzione di un vincolo di lunghezza della stringa è rara, depesz conclude che uno di essi è di solito la scelta migliore per un limite di lunghezza.

Come " Tipi di carattere " nei punti di documentazione fuori, varchar(n), char(n), e textsono tutti memorizzati nello stesso modo. L'unica differenza è che sono necessari cicli extra per controllare la lunghezza, se ne viene data una, e lo spazio e il tempo extra necessari se è necessaria l'imbottitura char(n).

Tuttavia, quando devi solo memorizzare un singolo carattere, c'è un leggero vantaggio prestazionale nell'usare il tipo speciale "char"(mantieni le virgolette doppie - fanno parte del nome del tipo). Ottieni un accesso più veloce al campo e non c'è un overhead per memorizzare la lunghezza.

Ho appena creato una tabella di 1.000.000 di casuali "char"scelti dall'alfabeto minuscolo. Una query per ottenere una distribuzione di frequenza ( select count(*), field ... group by field) richiede circa 650 millisecondi, contro circa 760 sugli stessi dati utilizzando un textcampo.

AGGIORNAMENTO DEI BENCHMARKS PER IL 2016 (pag. 9.5 +)

E usando benchmark "pure SQL" (senza alcuno script esterno)

1. usa qualsiasi string_generator con UTF8

2. parametri di riferimento principali:

   2.1. INSERIRE

   2.2. SELEZIONA il confronto e il conteggio

CREATE FUNCTION string_generator(int DEFAULT 20,int DEFAULT 10) RETURNS text AS $f$
  SELECT array_to_string( array_agg(
    substring(md5(random()::text),1,$1)||chr( 9824 + (random()*10)::int )
  ), ' ' ) as s
  FROM generate_series(1, $2) i(x);
$f$ LANGUAGE SQL IMMUTABLE;

Preparare test specifici (esempi)

DROP TABLE IF EXISTS test;
-- CREATE TABLE test ( f varchar(500));
-- CREATE TABLE test ( f text); 
CREATE TABLE test ( f text  CHECK(char_length(f)<=500) );

Eseguire un test di base:

INSERT INTO test  
   SELECT string_generator(20+(random()*(i%11))::int)
   FROM generate_series(1, 99000) t(i);

E altri test,

CREATE INDEX q on test (f);

SELECT count(*) FROM (
  SELECT substring(f,1,1) || f FROM test WHERE f<'a0' ORDER BY 1 LIMIT 80000
) t;

... E usa EXPLAIN ANALYZE.

AGGIORNATO ANCORA 2018 (pg10)

piccola modifica per aggiungere i risultati del 2018 e rafforzare i consigli.

Risultati nel 2016 e 2018

I miei risultati, dopo la media, in molte macchine e in molti test: tutti uguali
(deviazione standard statisticamente inferiore al tham).

Raccomandazione

• Usa il texttipo di dati,
  evita i vecchi varchar(x)perché a volte non è uno standard, ad esempio nelle CREATE FUNCTIONclausole varchar(x)≠varchar(y) .

• esprimere limiti (con le stesse varcharprestazioni!) di con CHECKclausola CREATE TABLE
  nell'es CHECK(char_length(x)<=10).
  Con una perdita trascurabile di prestazioni in INSERT / UPDATE è anche possibile controllare intervalli e struttura delle stringhe
  ad esCHECK(char_length(x)>5 AND char_length(x)<=20 AND x LIKE 'Hello%')

Sul manuale PostgreSQL

Non vi è alcuna differenza di prestazioni tra questi tre tipi, a parte un maggiore spazio di archiviazione quando si utilizza il tipo con riempimento vuoto e alcuni cicli CPU aggiuntivi per controllare la lunghezza durante l'archiviazione in una colonna con vincoli di lunghezza. Sebbene il carattere (n) presenti vantaggi in termini di prestazioni in alcuni altri sistemi di database, PostgreSQL non offre tali vantaggi; infatti il ​​carattere (n) è di solito il più lento dei tre a causa dei suoi costi di archiviazione aggiuntivi. Nella maggior parte dei casi, invece, è necessario utilizzare testo o caratteri diversi.

Di solito uso il testo

Riferimenti: http://www.postgresql.org/docs/current/static/datatype-character.html

Secondo me, varchar(n)ha i suoi vantaggi. Sì, usano tutti lo stesso tipo di base e tutto il resto. Tuttavia, va sottolineato che gli indici in PostgreSQL hanno un limite di dimensione di 2712 byte per riga.

TL; DR: se si utilizza il texttipo senza un vincolo e si hanno indici su queste colonne, è molto probabile che si raggiunga questo limite per alcune delle colonne e si ottenga un errore quando si tenta di inserire dati ma con l'utilizzo varchar(n), è possibile impedirlo.

Alcuni ulteriori dettagli: Il problema qui è che PostgreSQL non dà alcuna eccezione durante la creazione di indici per il texttipo o varchar(n)dove nè maggiore di 2712. Tuttavia, darà errore quando si tenta di inserire un record con dimensioni compresse superiori a 2712. Significa che puoi inserire facilmente 100.000 caratteri di stringa che sono composti da caratteri ripetitivi perché saranno compressi molto al di sotto di 2712 ma potresti non essere in grado di inserire una stringa con 4000 caratteri perché la dimensione compressa è maggiore di 2712 byte. Usando varchar(n)dove nnon è troppo grande di 2712, sei al sicuro da questi errori.

text e varchar hanno conversioni di tipo implicito differenti. L'impatto più grande che ho notato è la gestione degli spazi finali. Per esempio ...

select ' '::char = ' '::varchar, ' '::char = ' '::text, ' '::varchar = ' '::text

ritorna true, false, truee non true, true, truecome ci si potrebbe aspettare.

In qualche modo OT: se stai usando Rails, la formattazione standard delle pagine web potrebbe essere diversa. Per i moduli di immissione dati, le textcaselle sono scorrevoli, ma le caselle character varying(Rotaie string) sono a riga singola. Le visualizzazioni dello spettacolo sono lunghe quanto necessario.

Una buona spiegazione da http://www.sqlines.com/postgresql/datatypes/text :

L'unica differenza tra TEXT e VARCHAR (n) è che è possibile limitare la lunghezza massima di una colonna VARCHAR, ad esempio VARCHAR (255) non consente l'inserimento di una stringa lunga più di 255 caratteri.

Sia TEXT che VARCHAR hanno il limite superiore a 1 Gb e non vi sono differenze di prestazioni tra loro (secondo la documentazione di PostgreSQL).

character varying(n), varchar(n)- (Entrambi uguali). il valore verrà troncato a n caratteri senza generare un errore.

character(n), char(n)- (Entrambi uguali). a lunghezza fissa e riempirà con spazi vuoti fino alla fine della lunghezza.

text- Lunghezza illimitata.

Esempio:

Table test:
   a character(7)
   b varchar(7)

insert "ok    " to a
insert "ok    " to b

Otteniamo i risultati:

a        | (a)char_length | b     | (b)char_length
----------+----------------+-------+----------------
"ok     "| 7              | "ok"  | 2