Discussion :

[leoz2007]

Bien le bonjour

Cela fait un petit moment que je developpe du php/mysql/css/html et je me suis toujours pose la question suivante :
Comment déterminer la taille des varchars dans une structure de table ?

je travaille actuellement avec des noms d'utilisateurs propre a notre entreprise
(exemple: prenom_nom)

Je dois donc deviner plus ou moins le nom et prénom de mes users.
Pour les noms européens c'est un peu toujours pareil, mais les noms indiens c'est plus complique

Generalement lorsque je cree mes table je me laisse de la marge mais je me demande si SQL voit un inconvénient a ce que je lui spécifie 70 caractère alors que je ne dépasse jamais les 20

Merci a ceux qui m'auront lu

[CinePhil]

Prévoir une taille trop grande peut alourdir la BDD. Mais cela sera surtout sensible avec un grand nombre de données (plusieurs centaines de milliers).

je travaille actuellement avec des noms d'utilisateurs propre a notre entreprise

VARCHAR(70) au lieu de VARCHAR(20), ça fait 50 caractères de plus. S'il y a 1000 employés, ça ne fait que 50 000 octets de plus, ce n'est rien pour un SGBD !

Par contre, j'ose espérer que ce n'est pas la clé primaire de la table et qu'il existe une clé auto-incrémentée !

[leoz2007]

Non ce n'est pas ma cle primaire
On m'a toujours dis de se limiter a des int, smallint, tinyint en cles primaire afin de produire des ID's

Sinon pense tu que la fonction OPTIMIZE en SQL va diminuer les tailles de mes champs dans le cas present ?
Ou optmize n'est que pour la creation d'index ?

[CinePhil]

Je crois que OPTIMIZE réorganise les index et les tables qui ont eu des séries de suppressions/ajouts.

[StephaneC.]

L'effet d'OPTIMIZE dépend du moteur de stockage, mais en gros, ça défragmente les données, trie les index et met à jour les statistiques sur les index utilisées par l'optimiseur de requêtes.

Pour avoir une idée de la "bonne taille" à prendre, tu peux utiliser PROCEDURE ANALYSE :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT * FROM matable PROCEDURE ANALYSE(10,256)\G

Il faut être critique avec le résultat obtenu, surtout si tu as peu de données dans ta table.

Je te laisse voir dans la doc la signification des 2 paramètres de PROCEDURE ANALYSE...

Au sujet de la différence entre un VARCHAR(70) et un VARCHAR(20), a priori il n'y en a pas puisque justement le but du VARCHAR est d'adapter la taille du stockage à la donnée.

En réalité, c'est faux : pour des opérations comme les tris, MySQL va utiliser un buffer dans lequel il va placer les lignes à traiter pour faire l'opération. Et là, la taille mémoire utilisée est toujours le maximum possible pour chaque colonne. Si la taille indiquée dans la définition des champs est trop grande par rapport aux données, MySQL ne pourra pas faire tenir autant de lignes qu'il serait souhaitable dans ses buffers et les perfs vont chuter.

Dans le cas des VARCHAR, un autre paramètre intervient : le jeu de caractères. Par exemple, si tu utilises latin1, chaque caractère pèse 1 octet, un VARCHAR(20) pèse donc au maximum 20 octets (plus un octet pour indiquer la taille, bref...) alors qu'un VARCHAR(70) en utf8 pèse au maximum 210 octets. Cela signifie qu'un buffer de tri contiendra 10 fois moins de lignes si elles sont en VARCHAR(70) utf8 ! La pratique qui veut qu'on mette tout en utf8 par défaut est donc plutôt dangereuse.

Stéphane