Es gibt keinen Unterschied in der Leistung. Und es gibt keine versteckten Optimierungen aufgrund der Potenz von 2.
Das einzige, was einen Unterschied macht, wie Dinge gespeichert werden, ist das tatsächliche Daten. 100 Zeichen gespeichert in einem VARCHAR2(2000) Spalte werden genauso gespeichert wie 100 Zeichen, die in einem VARCHAR2(500) gespeichert sind Spalte.
Betrachten Sie die Länge als Geschäftseinschränkung , nicht als Teil des Datentyps. Die einzige Sache, die Ihre Entscheidung über die Länge beeinflussen sollte, sind die geschäftlichen Beschränkungen bezüglich der Daten, die dort eingegeben werden.
Bearbeiten :die einzige Situation, in der die Länge es tut einen Unterschied machen, ist, wenn Sie einen Index für diese Spalte benötigen. Ältere Oracle-Versionen (<10) hatten eine Beschränkung der Schlüssellänge, die beim Erstellen des Index überprüft wurde.
Auch wenn es in Oracle 11 möglich ist, ist es vielleicht nicht die klügste Wahl, einen Index für einen Wert mit 4000 Zeichen zu haben.
Bearbeiten 2 :
Also war ich neugierig und richtete einen einfachen Test ein:
create table narrow (id varchar(40));
create table wide (id varchar(4000));
Füllen Sie dann beide Tabellen mit Zeichenfolgen, die aus 40 'X' bestehen. Wenn es tatsächlich einen (wesentlichen) Unterschied zwischen der Speicherung gab, sollte sich dies beim Abrufen der Daten irgendwie zeigen, oder?
Beide Tabellen haben genau 1048576 Zeilen.
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>
Der vollständige Tabellenscan für beide Tabellen hat also genau dasselbe bewirkt. Was passiert also, wenn wir die Daten tatsächlich auswählen?
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>
Es gibt einen kleinen Unterschied bei den konsistenten Gets, aber das könnte am Caching liegen.
