Skillnaden mellan CHAR, VARCHAR och VARCHAR2

Oracle har tre datatyper för att lagra strängar. – CHAR, VARCHAR och VARCHAR2. Hur skiljer de sig från varandra? När ska du använda vilken?

Låt oss ta reda på svaren i den här artikeln.

Den enklaste saken ur vägen först: VARCHAR och VARCHAR2 är samma sak. Men att detta idag – detta kan komma att ändras. Ta en titt i Oracles dokumentation 10G Release 2:

Använd inte datatypen VARCHAR. Använd istället datatypen VARCHAR2. Även om datatypen VARCHAR för närvarande är synonymt med VARCHAR2, planeras datatypen VARCHAR att omdefinieras som en separat datatyp som används för teckensträngar med variabel längd som jämförs med olika jämförelsesemantik.

I den här artikeln används VARCHAR2 för att beteckna både VARCHAR och VARCHAR2 eftersom de är likvärdiga idag.

Hur skiljer sig CHAR och VARCHAR2 från varandra då?

Skillnaden är att CHAR(n) ALLTID kommer att vara n bytes lång. Om strängens längd är <n, kommer den att fyllas med blanksteg vid insättning för att säkerställa en längd på n. En VARCHAR2(n) å andra sidan kommer att vara 1 till n bytes lång. En kortare sträng som lagras som VARCHAR2 kommer INTE att fyllas med blanksteg.

Antag till exempel att du lagrar strängen ”ORATABLE” i ett CHAR(20)-fält och ett VARCHAR2(20)-fält. CHAR-fältet kommer att använda 22 byte (2 byte för inledande längd). VARCHAR2-fältet använder endast 10 byte (8 byte för strängen, 2 byte för den inledande längden).

För att sammanfatta, CHAR är VARCHAR2 som är uppstoppad till sin maximala längd.

Hur påverkar den här skillnaden SQL:

Det här ändrar det sätt på vilket strängar matchas i CHAR jämfört med VARCHAR2. Kolla in det i praktiken:

SQL> create table strings 2 (colchar char (20) 3 , colvarchar varchar2 (20));Table created.SQL>SQL> insert into strings 2 (colchar, colvarchar) 3 values 4 ('ORATABLE', 'ORATABLE');1 row created.SQL> -- Define a string variableSQL> var str varchar2(20)SQL> -- Give it a value with length < 20SQL> exec :str := 'ORATABLE'PL/SQL procedure successfully completed.SQL> -- Exact string match with CHARSQL> -- No result found!SQL> select 'found' found_flag 2 from strings 3 where colchar = :str;no rows selectedSQL> -- Padded string match with CHARSQL> -- Now it finds itSQL> select 'found' found_flag 2 from strings 3 where colchar = rpad(:str,20);FOUND-----found

Så du ser att utfyllnad med blanksteg gör skillnad för om CHAR-strängen matchas med en parameter med variabel längd. För att få en matchning måste du antingen rpadda värdet eller rtrimma kolumnen.

Inget sådant krav med VARCHAR2:

SQL> -- Exact string match with VARCHAR2SQL> -- Result found!SQL> select 'found' found_flag 2 from strings 3 where colvarchar = :str;FOUND-----found

När ska vi använda CHAR, när VARCHAR2?

Om du bara använder VARCHAR2 och struntar i CHAR gör du livet mycket enklare. Det finns ingen skillnad mellan de två förutom att CHAR använder mer utrymme när dina strängar inte alltid har den fasta maximala längden. Dessutom leder CHAR till mer förvirring när man skriver frågor.

Jag använder CHAR som databaskolumner endast för värden av typen Y/N. (Det finns ingen kolumn med datatyp BOOLEAN, kommer du ihåg?) Detta fungerar som en markör för en kolumn av typen ”flagga” eller ”switch” – men det kunde lika gärna ha varit VARCHAR2.

För alla andra strängar är det VARCHAR2.

Sammanfattning

När du betraktar Oracle-datatyperna CHAR, VARCHAR och VARCHAR2 ska du komma ihåg att:

• VARCHAR och VARCHAR2 är desamma, men funktionen för VARCHAR kan komma att ändras i framtiden. Använd VARCHAR2.
• CHAR och VARCHAR2 skiljer sig åt genom att CHAR blankar sina strängar så att de får maximal längd. VARCHAR2 gör ingen blank padding.
• På grund av ovanstående kräver frågor som involverar strängjämförelser på en CHAR-kolumn större försiktighet – en VARCHAR2 som jämförs med CHAR måste rpad-das för att få en träff.
• Det tål att upprepas: använd VARCHAR2!