Oracle har tre datatyper til lagring af strenge. – CHAR, VARCHAR og VARCHAR2. Hvordan adskiller de sig fra hinanden? Hvornår skal du bruge hvilke?
Lad os finde ud af svarene i denne artikel.
Den enkleste ting ud af vejen først: VARCHAR og VARCHAR2 er det samme. Men at dette i dag – det kan ændre sig. Tag et kig i Oracle-dokumentationen 10G Release 2:
Brug ikke datatypen
VARCHAR
. Brug i stedet datatypenVARCHAR2
i stedet. Selv omVARCHAR
-datatypen i øjeblikket er synonym medVARCHAR2
, er det planlagt, atVARCHAR
-datatypen skal omdefineres som en separat datatype, der bruges til tegnstrenge med variabel længde, der sammenlignes med forskellig sammenligningssemantik.
I denne artikel bruges VARCHAR2 til at betegne både VARCHAR og VARCHAR2, da de i dag er ækvivalente.
Hvordan er CHAR og VARCHAR2 så forskellige?
Den forskel er, at CHAR(n) ALTID vil være n bytes lang. Hvis strengen har en længde på <n, vil den blive blankpolstret ved indsættelse for at sikre en længde på n. En VARCHAR2(n) vil på den anden side være 1 til n bytes lang. En kortere streng, der er gemt som VARCHAR2, vil IKKE blive blank padded.
Fors eksempel: Lad os antage, at du gemmer strengen “ORATABLE” i et CHAR(20)-felt og et VARCHAR2(20)-felt. CHAR-feltet vil bruge 22 bytes (2 bytes til ledende længde). VARCHAR2-feltet vil kun bruge 10 bytes (8 til strengen, 2 bytes til ledende længde).
For at opsummere er CHAR VARCHAR2 polstret til den maksimale længde.
Hvordan påvirker denne forskel SQL’er?
Dette ændrer den måde, hvorpå strenge matches i CHAR vs. VARCHAR2. Se det i praksis:
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 kan se, at udfyldning med blanktegn gør en forskel for, om CHAR-strengen bliver matchet med en parameter med variabel længde. For at få et match skal du enten rpad værdien eller rtrimme kolonnen for at få et match.
Ingen sådanne 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
Hvornår skal vi bruge CHAR, hvornår VARCHAR2?
Hvis du kun nogensinde bruger VARCHAR2 og ignorerer CHAR, gør du livet meget enklere. Der er ingen forskel mellem de to, bortset fra at CHAR bruger mere plads, når dine strenge ikke altid har den faste maksimale længde. Desuden fører CHAR til mere forvirring ved skrivning af forespørgsler.
Jeg bruger kun CHAR som databasekolonner til værdier af Y/N-typen. (Der findes ikke nogen BOOLEAN-kolonne-datatype, husker du det?) Dette fungerer som en markering for en kolonne af typen “flag” eller “switch” – men det kunne lige så godt have været VARCHAR2.
For alle andre strenge er det VARCHAR2.
Summarum
Når du overvejer Oracle-datatyperne CHAR, VARCHAR og VARCHAR2, skal du huske følgende:
- VARCHAR og VARCHAR2 er det samme, men funktionen af VARCHAR kan ændre sig i fremtiden. Brug VARCHAR2.
- CHAR og VARCHAR2 er forskellige, idet CHAR blankpolerer sine strenge, så de har den maksimale længde. VARCHAR2 gør ingen blank padding.
- På grund af ovenstående kræver forespørgsler, der involverer stringsammenligning på en CHAR-kolonne, større forsigtighed – en VARCHAR2 sammenlignet med CHAR skal rpad-des for at få et hit.
- Det tåler at blive gentaget: Brug VARCHAR2!