Voorkeurskolommen van Oracle

Er is geen verschil in prestaties. En er zijn geen verborgen optimalisaties gedaan vanwege de kracht van 2.

Het enige dat een verschil maakt in hoe dingen worden opgeslagen, is de werkelijke gegevens. 100 tekens opgeslagen in een VARCHAR2(2000) kolom worden op precies dezelfde manier opgeslagen als 100 tekens die zijn opgeslagen in een VARCHAR2(500) kolom.

Zie de lengte als een zakelijke beperking , niet als onderdeel van het gegevenstype. Het enige dat uw beslissing over de lengte zou moeten bepalen, zijn de zakelijke beperkingen met betrekking tot de gegevens die daarin worden ingevoerd.

Bewerken :de enige situatie waarin de lengte doet een verschil maken, is wanneer u een index op die kolom nodig heeft. Oudere Oracle-versies (<10) hadden wel een limiet op de sleutellengte en dat werd gecontroleerd bij het maken van de index.

Ook al is het mogelijk in Oracle 11, het is misschien niet de verstandigste keuze om een ​​index te hebben op een waarde met 4000 tekens.

Bewerk 2 :

Dus ik was nieuwsgierig en zette een eenvoudige test op:

create table narrow (id varchar(40));
create table wide (id varchar(4000));

Daarna beide tabellen gevuld met strings bestaande uit 40 'X'. Als er inderdaad een (aanzienlijk) verschil was tussen de opslag, zou dit op de een of andere manier moeten blijken bij het ophalen van de gegevens, toch?

Beide tabellen hebben precies 1048576 rijen.

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>

Dus de volledige tafelscan voor beide tafels deed precies hetzelfde. Dus wat gebeurt er als we de gegevens daadwerkelijk selecteren?

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>

Er is een klein verschil in consistente Gets, maar dat kan te wijten zijn aan caching.