Il n'y a pas de différence de performances. Et il n'y a pas d'optimisations cachées effectuées à cause de la puissance de 2.
La seule chose qui fait une différence dans la façon dont les choses sont stockées est le réel Les données. 100 caractères stockés dans un VARCHAR2(2000) colonne sont stockés exactement de la même manière que 100 caractères stockés dans un VARCHAR2(500) colonne.
Considérez la longueur comme une contrainte commerciale , pas dans le cadre du type de données. La seule chose qui devrait guider votre décision concernant la longueur, ce sont les contraintes commerciales concernant les données qui y sont placées.
Modifier :la seule situation où la longueur fait faire une différence, c'est quand vous avez besoin d'un index sur cette colonne. Les anciennes versions d'Oracle (<10) avaient une limite sur la longueur de la clé et cela a été vérifié lors de la création de l'index.
Même si c'est possible dans Oracle 11, ce n'est peut-être pas le choix le plus judicieux d'avoir un index sur une valeur de 4000 caractères.
Modifier 2 :
J'étais donc curieux et j'ai mis en place un test simple :
create table narrow (id varchar(40));
create table wide (id varchar(4000));
Puis rempli les deux tableaux avec des chaînes composées de 40 'X'. S'il y avait effectivement une différence (substantielle) entre le stockage, cela devrait apparaître d'une manière ou d'une autre lors de la récupération des données, n'est-ce pas ?
Les deux tables ont exactement 1048576 lignes.
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>
Ainsi, l'analyse complète de la table pour les deux tables a fait exactement la même chose. Que se passe-t-il lorsque nous sélectionnons réellement les données ?
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>
Il existe une légère différence dans les obtentions cohérentes, mais cela peut être dû à la mise en cache.
