Ne, vůbec to není totéž.
- Délka sloupce je užitečná metadata pro vývojářské obrazovky.
- Podobně automatické dotazovací nástroje jako TOAD a SQL Developer používají při vykreslování výsledků délku sloupce.
- Při přidělování paměti pro kolekce PL/SQL databáze používá délku proměnné. Vzhledem k tomu, že tato paměť přichází z PGA supersizing, deklarace proměnné může vést k selhání programů, protože server má nedostatek paměti.
- Podobné problémy jsou s deklarací jednotlivých proměnných v programech PL/SQL, jen kolekce obvykle problém znásobují.
- Sloupce s nadměrnou velikostí způsobují problémy složeným indexům. Následující je na databázi s 8K bloky
....
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>
Ale především jsou velikosti sloupců formou kontroly chyb. Pokud má mít sloupec deset znaků a nějaký autonomní proces se pokouší načíst tisíc znaků, pak je něco špatně. Proces by měl selhat, takže můžeme prozkoumat, proč načítáme data duff. Alternativou je databáze plná smetí, a pokud to bylo to, co jsme chtěli, měli bychom dát všem Excel a udělat s tím.
Je pravda, že změnit velikost sloupce, když se ukáže, že jsme to podcenili, může být únavné. Ale nestává se to příliš často a mnoho bolesti můžeme zmírnit použitím deklarací %TYPE a SUBTYPE v našem PL/SQL namísto pevně zakódovaných délek proměnných.
Čísla jsou různá. Pro začátek je maximální velikost čísla mnohem menší než textový ekvivalent (38 číslic se zaručenou přesností).
Ale hlavní rozdíl je v tom, že Oracle ukládá číselné hodnoty v vědecký zápis takže neexistuje přímý vztah mezi aritmetickou velikostí čísla a úložným prostorem, který spotřebuje.
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>
Nicméně i nadále zůstává dobrou praxí specifikovat měřítko a přesnost všude, kde je to možné, zvláště když se zabýváme řekněme celými čísly nebo penězi.