Bonjour,
 
J'ai une question existentielle pour le choix entre char et varchar. Je sais que si on prend un char(3) par exemple il réserve d'office la place pour 3 caractères. Mais si je fait un varchar(3) je suppose qu'il doit avoir un endroit ou il stoque la taille donc au final mon varchar(3) ne prendra t il pas plus de place que mon char(3)? A partir de combien de caractères ca devient intéressant?
 
D'avance merci si vous avez des infos! Je suis en MsSql!
 
Benjamin

char <- caractère de bourrage (typiquement des espaces), taille fixe
varchar <- pas de bourrage, taille variable dans la limite fixée.
 
après selon ton SGBD, si'l est pourri ou pas, t'auras des mésaventures de trucs tantot bourré ou pas, quand ils ne le devraient pas ou si.

En cherchant sur le net j ai eu 2 avis contradictoires il y en a un qui dit que de toutes facons il y a un alogrithme de compression qui fait que la place sur le disque est la meme au final.
Source: http://www.volny.cz/iprenosil/inte [...] trings.htm
 
Et un autre me dit (mais en MySql) que le varchar ajoute 2 bytes et que donc les varchar devient vraiment intéressant à partir de 18 char
Source: http://archives.postgresql.org/pgs [...] g00520.php

et alors ? De toutes façons, ce sont deux types de données au comportement différents. Leur implémentation est complètement dépendante du SGBRD en dessous. Certains SGBD stocke de toutes façons tout ce qui est chaine dans des tables internes dédiés, sans gachi de place ni rien.
 
Optimisation prématurée, toussa. Choisi le type adéquat déjà. Pour le reste, regarde avec ton SGBDR s'il a des fonction pour mesurer précisément le poids d'une table remplie (le poids de chaque ligne est évidemment différent).

Le message initial sur http://archives.postgresql.org/pgs [...] g00520.php est parfait.

PS: même si nous racontes que c'est pour une base de données de la NASA en titane pour stocker des milliards de milliards de trucs, au prix que coute le To, ça ne fait aucune différence.

Non je m en fout un peu au final car j ai des petites DB s'était juste par curiosité!

et surtout le char c'est chiant, faut toujours trimer pour faire une comparaison, c'est juste pénible...

un char ça ne sert que pour stocker une valeur qui a toujours la même longueur, telle un code ou une date par exemple.
 
genre le code ISO d'un pays on sait que ça fait toujours 2 ou 3 lettres (selon la norme ISO retenue). à ce moment, un char est intéressant. pour le reste, varchar est le plus dédié aux chaînes de caractères, puisque c'est aussi comme ça que ton programme consommateur/fournisseur va gérer les données en mémoire : donc pas de trim/pad inutiles

euh, je ne pense pas qu'il faille pour autant trimer à chaque fois un char

ben si ton champs est de type char(10) et que tu veuilles trouver la valeur 'toto' soit tu fais un champ = 'toto      ' soit un trim(champ)= 'toto' , donc a moi d'aimer les problèmes le trim est quasi indispensable

Si tu attends un nom de personne, alors si :
 

SELECT * FROM gens WHERE nom = 'MagicBuzz'

 
Retournera jamais rien si "nom" n'est pas un char(9)"
 
il faudra à la place utiliser (si nom = char(12))
 

SELECT * FROM gens WHERE nom = rpad('MagicBuzz', 12)

 
ou
 

SELECT * FROM gens WHERE rtrim(nom) = 'MagicBuzz'

 
ou
 

SELECT * FROM gens WHERE nom LIKE 'MagicBuzz%'

(avec un résultat aléatoirement faut)
 
et surtout, la troncature est faite implicitement :
 
isocode = char(2)
 

SELECT * FROM pays WHERE isocode = 'FRA'

SELECT * FROM pays WHERE isocode = 'FRI'

 
=> Les deux requêtes retournent la ligne "FR" sans le moindre warning. alors qu'avec un varchar(2) aucune n'aurait retourné de valeur
 
idem pour l'insertion : inserrer une valeur trop grande dans un char tronque la valeur sans crier gare. avec un varchar tu te tapes une erreur (cf norme SQL)

oki oki MagicBuzz. Je remercie de m'avoir expliquer avec des exemples. C'est tres claire dans ma tete maintenant.  
 
Je comprends maintenant pour on avait conseillé à mon collègue d'utiliser varchar2 tout le temps plutot que char.
 
char est en théorie légèrement plus performant mais n'est pas très pratique à l'usage.