Non c'è differenza nelle prestazioni. E non ci sono ottimizzazioni nascoste fatte a causa della potenza di 2.
L'unica cosa che fa la differenza nel modo in cui le cose vengono archiviate è il effettivo dati. 100 caratteri memorizzati in un VARCHAR2(2000) vengono memorizzate esattamente allo stesso modo di 100 caratteri memorizzati in un VARCHAR2(500) colonna.
Pensa alla lunghezza come a un vincolo commerciale , non come parte del tipo di dati. L'unica cosa che dovrebbe guidare la tua decisione sulla lunghezza sono i vincoli aziendali sui dati che vengono inseriti.
Modifica :l'unica situazione in cui la lunghezza fa fare la differenza, è quando hai bisogno di un indice su quella colonna. Le versioni precedenti di Oracle (<10) avevano un limite alla lunghezza della chiave e questo è stato verificato durante la creazione dell'indice.
Anche se è possibile in Oracle 11, potrebbe non essere la scelta più saggia avere un indice su un valore con 4000 caratteri.
Modifica 2 :
Quindi ero curioso e ho impostato un semplice test:
create table narrow (id varchar(40));
create table wide (id varchar(4000));
Quindi ha riempito entrambe le tabelle con stringhe composte da 40 'X'. Se c'era davvero una (sostanziale) differenza tra l'archiviazione, questa dovrebbe apparire in qualche modo durante il recupero dei dati, giusto?
Entrambe le tabelle hanno esattamente 1048576 righe.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> set autotrace traceonly statistics
SQL> select count(*) from wide;
Statistics
----------------------------------------------------------
0 recursive calls
1 db block gets
6833 consistent gets
0 physical reads
0 redo size
349 bytes sent via SQL*Net to client
472 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select count(*) from narrow;
Statistics
----------------------------------------------------------
0 recursive calls
1 db block gets
6833 consistent gets
0 physical reads
0 redo size
349 bytes sent via SQL*Net to client
472 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>
Quindi la scansione completa della tabella per entrambe le tabelle ha fatto esattamente lo stesso. Quindi cosa succede quando selezioniamo effettivamente i dati?
SQL> select * from wide;
1048576 rows selected.
Statistics
----------------------------------------------------------
4 recursive calls
2 db block gets
76497 consistent gets
0 physical reads
0 redo size
54386472 bytes sent via SQL*Net to client
769427 bytes received via SQL*Net from client
69907 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1048576 rows processed
SQL> select * from narrow;
1048576 rows selected.
Statistics
----------------------------------------------------------
4 recursive calls
2 db block gets
76485 consistent gets
0 physical reads
0 redo size
54386472 bytes sent via SQL*Net to client
769427 bytes received via SQL*Net from client
69907 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1048576 rows processed
SQL>
C'è una leggera differenza nei get coerenti, ma ciò potrebbe essere dovuto alla memorizzazione nella cache.
