Hvad er den største forskel mellem Varchar2 og char

Selvom der allerede er flere svar, der korrekt beskriver chars adfærd , jeg tror, ​​det skal siges, at du skal ikke bruge det undtagen i tre specifikke situationer:

1. Du bygger en fil eller rapport med fast længde og tildeler en ikke-nul værdi til en char undgår behovet for at kode en rpad() udtryk. For eksempel hvis firstname og lastname er begge defineret som char(20) , derefter firstname || lastname er en kortere måde at skrive rpad(firstname,20) || rpad(lastname,20) for at oprette Chuck Norris .
2. Du skal skelne mellem den eksplicitte tomme streng '' og null . Normalt er de det samme i Oracle, men tildeler '' til en char værdi vil udløse dens tomfyldningsadfærd, mens null vil ikke, så hvis det er vigtigt at se forskel, og jeg ikke rigtig kan komme i tanke om en grund til, hvorfor det ville være det, så har du en måde at gøre det på.
3. Din kode er porteret fra (eller skal være kompatibel med) et andet system, der kræver blank udfyldning af ældre årsager. I så fald sidder du fast med det, og du har min sympati.

Der er virkelig ingen grund til at bruge char bare fordi en eller anden længde er fast (f.eks. en Y/N flag eller en ISO-valutakode såsom 'USD' ). Det er ikke mere effektivt, det sparer ikke plads (der er ingen mytisk længdeindikator for en varchar2 , der er bare en tom polstring overhead for char ), og det forhindrer ikke nogen i at indtaste kortere værdier. (Hvis du indtaster 'ZZ' i din char(3) valutakolonnen, bliver den bare gemt som 'ZZ ' .) Den er ikke engang bagudkompatibel med en gammel version af Oracle, der engang stolede på den, fordi der aldrig har været en.

Og smitten kan sprede sig, da du (ved at følge bedste praksis) måske forankre en variabel erklæring ved hjælp af noget som sales.currency%type . Nu er din l_sale_currency variabel er en stealth char som vil blive usynligt blankpolstret for kortere værdier (eller '' ), åbner døren til obskure fejl, hvor l_sale_currency er ikke lig med l_refund_currency selvom du har tildelt 'ZZ' til dem begge.

Nogle hævder, at char(n) (hvor n er en vis tegnlængde) angiver, at værdier forventes at være n tegn lange, og dette er en form for selvdokumentation. Men hvis du er seriøs omkring et 3-tegns format (ISO-Alpha-3 landekoder i stedet for ISO-Alpha-2, for eksempel), ville du ikke definere en begrænsning for at håndhæve reglen i stedet for at lade udviklere kigge på en char(3) datatype og drage deres egne konklusioner?

CHAR blev introduceret i Oracle 6 af, jeg er sikker på, ANSI-kompatibilitetsårsager. Sandsynligvis er der potentielle kunder, der bestemmer hvilket databaseprodukt de skal købe og ANSI-kompatibilitet er på deres tjekliste (eller plejede at være dengang), og CHAR med blank-polstring er defineret i ANSI-standarden, så Oracle skal levere det. Det er ikke meningen, at du rent faktisk skal bruge det.