Oracle 12c - presterar index på en "nummer" kolumn snabbare än index på "varchar" kolumn?

[TL;DR] Använd datum för att lagra datum, siffror för att lagra siffror och strängar för att lagra strängar.

Oracle lagrar NUMBER datatyp som 1 byte per 2 siffror.

Oracle lagrar CHAR datatyp som 1 byte per ASCII-tecken (UTF-8 och andra kodningar kan ta mer för tecken i utökade uppsättningar) och kommer att högerutfylla strängen med blanksteg så att strängarna alla är exakt lika långa.

Oracle lagrar VARCHAR2 datatyp som 1 byte per ASCII-tecken plus en liten overhead (1 eller 2 byte) för stränglängden.

Oracle lagrar DATE datatyp som 7 byte (2 för år och 1 för varje månad, dag, timme, minut, sekund).

Baserat på din tidigare fråga du verkar lagra year och quarter och förutsatt att du alltid kommer att ha 4-siffriga årtal och 1-siffriga kvartal då:

• NUMBER(5,0) skulle ta 3 byte;
• CHAR(5 CHARACTER) skulle ta 5 byte;
• VARCHAR2(5 CHARACTER) skulle ta 6 byte; och
• DATE skulle ta 7 byte.

Så bara med tanke på minnet ett NUMBER(5,0) skulle vara det mest effektiva.

Men

Så fort du börjar räkna med år/kvartal lagrade som siffror/strängar kommer du in på prestandaproblem:

Till exempel, få nästa kvartal :

• Om quarter är ett NUMBER datatyp då kan du använda:CASE WHEN MOD(quarter,10) = 4 THEN quarter + 7 ELSE quarter + 1 END men det här hanterar inte när du vill lägga till 5 fjärdedelar eller börja subtrahera fjärdedelar och sedan börjar logiken bli mycket mer komplicerad.
• Om quarter är en CHAR datatyp då kan du konvertera den till ett tal eller ett datum och använda någon av dessa metoder (strängmanipulation kommer sannolikt inte att fungera).
• Om quarter är ett DATE då behöver du bara använda ADD_MONTHS( quarter, 3 ) .

DATE Metoden är självdokumenterande och existerar redan medan NUMBER metod skulle bara bli en anpassad funktion för din approximation av en QUARTER datatyp och när du implementerar alla jämförelse- och manipulationsfunktioner du behöver har du effektivt skrivit om DATE datatyp som en UDT för kvartal och dessa funktioner kommer att fungera mindre än de optimerade datumfunktionerna.

Använd inte olämpliga datatyper – spara bara datum som datum; siffror som siffror; och strängar som strängar.