Nee, het is helemaal niet hetzelfde.
- De lengte van de kolom is nuttige metadata voor ontwikkelaars die schermen bouwen.
- Eveneens automatische querytools zoals TOAD en SQL Developer gebruiken de lengte van de kolom wanneer ze resultaten weergeven.
- De database gebruikt de lengte van een variabele bij het toewijzen van geheugen voor PL/SQL-verzamelingen. Als dat geheugen uit de PGA komt, kan het groter worden van de variabeledeclaratie ertoe leiden dat programma's mislukken omdat de server geen geheugen meer heeft.
- Er zijn vergelijkbare problemen met de declaratie van enkele variabelen in PL/SQL-programma's, alleen hebben verzamelingen de neiging om het probleem te vermenigvuldigen.
- Supergrote kolommen veroorzaken problemen voor samengestelde indexen. Het volgende staat op een database met 8K blokken
....
SQL> create table t23 (col1 varchar2(4000), col2 varchar2(4000))
2 /
Table created.
SQL> create index t23_i on t23(col1,col2)
2 /
create index t23_i on t23(col1,col2)
*
ERROR at line 1:
ORA-01450: maximum key length (6398) exceeded
SQL>
Maar bovenal zijn kolomgroottes een vorm van foutcontrole. Als de kolom tien tekens lang zou moeten zijn en een of ander autonoom proces probeert duizend tekens te laden, dan is er iets mis. Het proces zou moeten mislukken, dus we kunnen onderzoeken waarom we duff-gegevens laden. Het alternatief is een database vol rommel, en als dat was wat we wilden, hadden we iedereen gewoon Excel moeten geven en ermee klaar moeten zijn.
Het is waar dat het vermoeiend kan zijn om de kolomgrootte te wijzigen wanneer blijkt dat we deze hebben onderschat. Maar het gebeurt niet vaak, en we kunnen veel van de pijn verzachten door %TYPE- en SUBTYPE-declaraties in onze PL/SQL te gebruiken in plaats van hardcoderende variabele lengtes.
Cijfers zijn anders. Om te beginnen is de maximale grootte van een getal veel kleiner dan het tekstequivalent (38 cijfers met gegarandeerde precisie).
Maar het belangrijkste verschil is dat Oracle numerieke waarden in wetenschappelijke notatie er is dus geen duidelijke relatie tussen de rekenkundige grootte van het nummer en de opslagruimte die het in beslag neemt.
SQL> select vsize(123456789012345678901) n1
2 , vsize(999999999999999999999999999999) n2
3 , vsize(0.000000000000000000001) n3
4 , vsize(1000000000000000000000000) n4
5 from dual
6 /
N1 N2 N3 N4
---------- ---------- ---------- ----------
12 16 2 2
SQL>
Niettemin blijft het een goede gewoonte om waar mogelijk schaal en precisie te specificeren, vooral als we te maken hebben met gehele getallen, bijvoorbeeld of geld.