Discussion :

[salutagama]

Bonjour, lorsque dans une base de données,
de nombreux attributs sont surdimensionnés.

J'entends par là par exemple que des attributs n'aurait pas de saisie de plus de 3, 10 ou 20 caractères alors qu'ils sont laissés par défaut en varchar(255) et que donc de l'espace mémoire est pris pour rien.

Quels sont les problèmes qui peuvent advenir ??

Des problèmes lors d'une éventuelle mise à jour de la BDD?? lors de la recherche dans la BDD?

[Waldar]

Ça dépend le moteur de la base de données, mais l'impact sur 255 est probablement très minime, en terme de stockage ça ne change rien (le varchar étant variable par nature), il y a quelques opérations type agrégat où certains moteurs doivent compléter avec des espaces jusqu'à la longueur maximale, mais à moins que votre requête analyse un volume de données très conséquent, peu de chance que ce soit significatif.

Voyez plutôt les longueurs maximales comme une contrainte concernant les données que vous souhaitez écrire.

[vanagreg]

Bonjour,

Lors de la modélisation il vaut mieux en effet définir une taille max proche de la réalité. Ça ne sert à rien de définir une colonne varchar2(255) si on sait pertinemment qu'elle ne dépassera jamais 10 caractères par exemple.
Maintenant avec les capacités de stockage élevé l'impact ne devrait pas être énorme. Il peut y avoir des problèmes par exemple pour les index, si les colonnes indexées sont définies au max (varchar2(4000) par exemple).


Concernant l'utilisation de variables définies avec des grandes tailles, oui l'espace alloué en mémoire sera plus important, mais avec les machines actuelles c'est rarement un problème.

[SQLpro]

Je vous confirme que l'impact est peu important sauf pour le cas ou le surdimensionnement est énorme et pour certaines opérations ou l'alignement des longueurs est nécessaire. En particulier comme le dit Waldar, les GROUP BY mais aussi les DISTINCT (une forme de GROUP BY) et les UNION / INTERSECT et EXCEPT (qui intègrent un DISTINCT).

Je me souviens que lors d'un audit d'une base dont les développeurs avaient mis partout du VARCHAR(8000) certaines requêtes consommaient une place gigantesque en mémoire lors de l'exécution , alors que le volume du résultat était ridicule...

A +

[escartefigue]

J'ajoute à ce qui précède que le varchar, en cas de mise à jour avec modification de la longueur du contenu, peut provoquer des déplacements dans les pages data et index ^*, ce qui bien entendu pénalise les performances. De plus, le varchar requiert un attribut pour stocker la longueur effective, qui ajoute 1 à 3 octets à la longueur de la donnée.
C'est pourquoi, pour des longueurs aussi petites que 3, 10 ou 20 octets, je lui préfère du char fixe.

^* : exception faite de postgresql dont la gestion très particulière des update fonctionne differemment

[SQLpro]

...^* : exception faite de postgresql dont la gestion très particulière des update fonctionne differemment

En pire ! Copies des versions des lignes dans les pages....

A +