Non, ce n'est pas du tout la même chose.
- La longueur de la colonne est une métadonnée utile pour les développeurs qui créent des écrans.
- Des outils de requête automatique similaires tels que TOAD et SQL Developer utilisent la longueur de la colonne lorsqu'ils affichent les résultats.
- La base de données utilise la longueur d'une variable lors de l'allocation de mémoire pour les collections PL/SQL. Au fur et à mesure que cette mémoire sort du PGA, le surdimensionnement de la déclaration de variable peut entraîner l'échec des programmes car le serveur manque de mémoire.
- Il existe des problèmes similaires avec la déclaration de variables uniques dans les programmes PL/SQL, c'est juste que les collections ont tendance à multiplier le problème.
- Les colonnes surdimensionnées créent des problèmes pour les index composés. Ce qui suit est sur une base de données avec des blocs de 8K
....
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>
Mais par-dessus tout, la taille des colonnes est une forme de vérification des erreurs. Si la colonne est censée contenir dix caractères et qu'un processus autonome essaie de charger un millier de caractères, quelque chose ne va pas. Le processus devrait échouer, nous pouvons donc rechercher pourquoi nous chargeons des données duff. L'alternative est une base de données pleine de déchets, et si c'était ce que nous voulions, nous aurions simplement dû donner Excel à tout le monde et en finir avec.
Il est vrai que changer la taille des colonnes lorsqu'il s'avère que nous avons sous-estimé peut être fastidieux. Mais cela n'arrive pas très souvent, et nous pouvons atténuer une grande partie de la douleur en utilisant les déclarations %TYPE et SUBTYPE dans notre PL/SQL au lieu de coder en dur des longueurs variables.
Les chiffres sont différents. Pour commencer, la taille maximale d'un nombre est beaucoup plus petite que l'équivalent texte (38 chiffres de précision garantie).
Mais la principale différence est qu'Oracle stocke les valeurs numériques dans notation scientifique il n'y a donc pas de relation directe entre la taille arithmétique du nombre et l'espace de stockage qu'il consomme.
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>
Néanmoins, il reste une bonne pratique de spécifier l'échelle et la précision dans la mesure du possible, en particulier lorsqu'il s'agit de nombres entiers, par exemple, ou d'argent.
