Wat is het grote verschil tussen Varchar2 en char

Hoewel er al verschillende antwoorden zijn die het gedrag van char . correct beschrijven , ik denk dat het moet worden gezegd dat je het niet moet gebruiken behalve in drie specifieke situaties:

1. U bouwt een bestand of rapport met een vaste lengte en wijst een niet-null-waarde toe aan een char vermijdt de noodzaak om een ​​rpad() . te coderen uitdrukking. Als bijvoorbeeld firstname en lastname zijn beide gedefinieerd als char(20) , dan firstname || lastname is een kortere manier van schrijven rpad(firstname,20) || rpad(lastname,20) om Chuck Norris te maken .
2. Je moet onderscheid maken tussen de expliciete lege tekenreeks '' en null . Normaal gesproken zijn ze hetzelfde in Oracle, maar met het toewijzen van '' naar een char waarde zal zijn blanco-opvulgedrag activeren terwijl null niet, dus als het belangrijk is om het verschil te zien, en ik kan niet echt een reden bedenken waarom dat zo zou zijn, dan heb je een manier om dat te doen.
3. Je code is geporteerd van (of moet compatibel zijn met) een ander systeem waarvoor blanco opvulling vereist is vanwege legacy-redenen. In dat geval zit je eraan vast en heb je mijn medeleven.

Er is echt geen reden om char te gebruiken alleen omdat een bepaalde lengte vast is (bijv. een Y/N vlag of een ISO-valutacode zoals 'USD' ). Het is niet efficiënter, het bespaart geen ruimte (er is geen mythische lengte-indicator voor een varchar2 , er is alleen een lege opvul-overhead voor char ), en het weerhoudt niemand ervan om kortere waarden in te voeren. (Als u 'ZZ' invoert in je char(3) valutakolom, wordt deze gewoon opgeslagen als 'ZZ ' .) Het is zelfs niet achterwaarts compatibel met een oude versie van Oracle die er ooit op vertrouwde, omdat er nooit een was.

En de besmetting kan zich verspreiden, aangezien u (volgens best practice) een variabele declaratie kunt verankeren met iets als sales.currency%type . Nu uw l_sale_currency variabele is een stealth char die onzichtbaar blanco wordt ingevuld voor kortere waarden (of '' ), de deur openen om bugs te verbergen waar l_sale_currency is niet gelijk aan l_refund_currency ook al heb je 'ZZ' . toegewezen aan beiden.

Sommigen beweren dat char(n) (waar n is een tekenlengte) geeft aan dat de waarden naar verwachting n . zijn tekens lang, en dit is een vorm van zelfdocumentatie. Maar als u serieus bent over een indeling met drie tekens (ISO-Alpha-3-landcodes in plaats van ISO-Alpha-2, bijvoorbeeld), zou u dan geen beperking definiëren om de regel af te dwingen, in plaats van ontwikkelaars een blik te laten werpen op een char(3) datatype en hun eigen conclusies trekken?

CHAR werd geïntroduceerd in Oracle 6 voor, ik weet zeker, ANSI-compatibiliteitsredenen. Waarschijnlijk zijn er potentiële klanten die beslissen welk databaseproduct ze willen kopen en ANSI-compatibiliteit op hun checklist staat (of was toen), en CHAR met blanco opvulling is gedefinieerd in de ANSI-standaard, dus Oracle moet deze leveren. Het is niet de bedoeling dat je het daadwerkelijk gebruikt.