Vad är den största skillnaden mellan Varchar2 och char

Även om det redan finns flera svar som korrekt beskriver beteendet hos char , jag tror att det måste sägas att du inte ska använda det förutom i tre specifika situationer:

1. Du bygger en fil eller rapport med fast längd och tilldelar ett värde som inte är null till en char undviker behovet av att koda en rpad() uttryck. Till exempel om firstname och lastname är båda definierade som char(20) , sedan firstname || lastname är ett kortare sätt att skriva rpad(firstname,20) || rpad(lastname,20) för att skapa Chuck Norris .
2. Du måste skilja på den explicita tomma strängen '' och null . Normalt är de samma sak i Oracle, men tilldelar '' till en char värde kommer att utlösa dess tomfyllningsbeteende medan null kommer inte att göra det, så om det är viktigt att se skillnad och jag inte riktigt kan komma på en anledning till varför det skulle vara det, så har du ett sätt att göra det.
3. Din kod är porterad från (eller måste vara kompatibel med) något annat system som kräver blank utfyllnad av äldre skäl. I så fall har du fastnat för det och du har min sympati.

Det finns verkligen ingen anledning att använda char bara för att en viss längd är fast (t.ex. en Y/N flagga eller en ISO-valutakod som 'USD' ). Det är inte mer effektivt, det sparar inte utrymme (det finns ingen mytisk längdindikator för en varchar2 , det finns bara en tom utfyllnad för char ), och det hindrar inte någon från att ange kortare värden. (Om du anger 'ZZ' i din char(3) valutakolumnen, kommer den bara att lagras som 'ZZ ' .) Den är inte ens bakåtkompatibel med någon gammal version av Oracle som en gång förlitade sig på den, eftersom det aldrig fanns någon.

Och smittan kan spridas, eftersom du (enligt bästa praxis) kanske förankrar en variabeldeklaration med något som sales.currency%type . Nu är din l_sale_currency variabel är en stealth char som kommer att bli osynligt tom vadderad för kortare värden (eller '' ), öppnar dörren till obskyra buggar där l_sale_currency är inte lika med l_refund_currency även om du tilldelade 'ZZ' till dem båda.

Vissa hävdar att char(n) (där n är en viss teckenlängd) indikerar att värden förväntas vara n tecken långa, och detta är en form av självdokumentation. Men om du menar allvar med ett 3-teckenformat (ISO-Alpha-3 landskoder snarare än ISO-Alpha-2, till exempel), skulle du inte definiera en begränsning för att upprätthålla regeln, snarare än att låta utvecklare titta på en char(3) datatyp och dra sina egna slutsatser?

CHAR introducerades i Oracle 6 av, jag är säker på, ANSI-kompatibilitetsskäl. Förmodligen finns det potentiella kunder som bestämmer vilken databasprodukt de ska köpa och ANSI-kompatibilitet finns på deras checklista (eller brukade vara då) och CHAR med blank stoppning definieras i ANSI-standarden, så Oracle måste tillhandahålla det. Det är inte meningen att du faktiskt ska använda den.