Discussion :

[Nemesis007]

Salut a tous,

Avec un membre de mon trinome nous avons un different sur le type d'un ID. En esperant avoir une reponse d'un expert (sinon il n'y croira pas ^^), est ce que le type est un INT ou un VARCHAR ?

Merci

[CinePhil]

ID désigne habituellement un identifiant de la ligne d'une table.
Ce n'est généralement pas une donnée que l'on montre à l'utilisateur final parce que c'est un code anonyme totalement inutile en tant que donnée à gérer. Par contre, c'est ce qui sert comme clé primaire des tables non associatives et comme clé étrangère dans les tables associées.

Pour des raisons de performance maintes fois expliquées sur ce forum, la clé primaire sera de type entier non signé non null et auto-incrémenté. Un recherche sur un entier est beaucoup plus rapide que sur un VARCHAR.

Et ceci reste valable même si une colonne de type VARCHAR est clé candidate pour une table.

Un exemple...

Soit une table abritant les données sur des employés d'une entreprise. Cette entreprise attribue à chaque employé un groupe de lettres de manière à l'identifier de manière unique. Ce code sert de login utilisateur sur le réseau de l'entreprise et d'abréviation pour l'expéditeur et/ou le destinataire dans les correspondances internes et externes.
Le code est constitué des initiales du nom de l'employé. Si ces initiales sont déjà prises par un autre employé, on ajoute la deuxième lettre du nom, ou la troisième... puis la deuxième du prénom, ou la troisième...
Jean Dupont ==> JD
Jeanne Durand ==> JDU
Jules Duparc ==> JDP
...

A première vue, le code de l'employé est une clé candidate sympathique.
Mais si on l'utilise comme clé primaire de la table des employés, ce code va servir de clé étrangère dans les autres tables (congés, salaires, absences...).
Si Jeanne Durand se marie et change de nom, l'entreprise a décidé de changer ses intiales. Il faudra alors changer également ce code dans toutes les tables ou celui-ci est clé étrangère !

Avec une clé primaire anonyme de type entier non signé non-null et auto-incrémenté, il suffit de changer le code dans la table des employés.
Les données sont plus robustes.

Employes (E_Id, E_Code, E_Nom, E_Prenom, E_Adresse, E_DateNaissance...)

[SQLpro]

A lire pour clore le débat :
COMMANDEMENT N°2
dans : http://blog.developpez.com/sqlpro/p6...-sur-ms-sql-s/

J'ai d'ailleurs rajouté un paragraphe spécialement pour traiter votre cas :

"
Assenons un dernier coup... Avec un CHAR de 4 identique en cout de stockage à un INTEGER (ne prenons pas un VARCHAR de 4 c'est idiot, il lui faut 6 octets au pire car il doit en sus stocker la longueur réelle de la donnée), combien de valeurs différentes de clefs puis-je stocker ? 4 x 8 = 32 => 2^32 - 1... Soit 4 294 967 295 ? Eh bien pas du tout... En effet la table des caractères compte déjà 32 caractères non imprimables (ceux de 0 à 1F en hexadécimal, comme par exemple la sonnette 7 !). Donc en théorie votre clavier vous permet donc (256 - 32) ^ 4 = 2 517 630 976 C'est déjà 2 fois moins de clefs possible. Mais allez-vous franchement demander à vos clients de saisir comme code : #"{,|@ùÈ ??? Donc si l'on enlève tous les caractères de ponctuation et les lettres accentuées, il vous reste exactement 62 caractères en comptant majuscule et minuscule. Et comme le risque est grand de se tromper dans la saisie d'un code comme dEfH0iI, vous en viendrez a ne plus devoir faire de différence entre majuscules et minuscules ce qui vous réduit les possibilités aux 26 lettres de l'alphabet et aux 10 chiffres soit 36 combinaisons, c'est à dire au plus 36 ^ 4 valeurs de clefs possible soit 1 679 616 combinaisons. Quelle excellent rendement que d'avoir perdu 99,92 % de clefs potentielles. Que dirait-on d'un moteur dont le rendement est de 0,01 % ?
"

A +

[pacmann]

Salut !

Rien à redire sur le sujet...
Mais une petite remarque par rapport à un truc que j'ai lu récemment sur ce forum :

Avec un CHAR de 4 identique en cout de stockage à un INTEGER (ne prenons pas un VARCHAR de 4 c'est idiot, il lui faut 6 octets au pire car il doit en sus stocker la longueur réelle de la donnée)

La longueur du char et du varchar existe et est stockée dans les deux types, sur deux octets.
Mais votre char prendra toujours sa longueur maximale, dans votre exemple un char(2) fera toujours 4 octets là où un varchar(2) oscillera entre 3 et 4 octets.

Si vous êtes sûr de votre donnée et que cette dernière fait toujours deux octets, les deux types fonctionneront de manière strictement identique.

Et la petite citation de Tom Kytes (comparaison entre char(10) et varchar2(10), voir ici):
If the field is in fact ALWAYS 10 bytes long, using a CHAR will not hurt -- HOWEVER, it will not help either.

The only time I personally use a CHAR type is for CHAR(1). And that is only because its faster to type char(1) then varchar2(1) -- it offers no advantages

Donc disons que c'est peut être idiot, mais pas sur tous les SGBD

PS: Vive Oracle, Vive Tom Kyte !

[SQLpro]

La longueur du char et du varchar existe et est stockée dans les deux types, sur deux octets.

ça c'est valable sur les mauvais SGBDR (). Je peut te dire que ce n'est pas le cas sur la lignée Ingres donc :
1) INGRES
2) SYBASE
3) SQL SERVER
4) PostGreSQL
Je crois d'ailleurs que c'est aussi le cas d'InterbAse / Firebird

A +

[pacmann]

Hmmm, ok.
Donc seul Oracle fait ça...
C'est vrai que c'est du gachis... une idée de la raison ? (choix d'implémentation, ou connerie historique)

[SQLpro]

Peut être que MySQL se solidarise avec Oracle ???? Pour ne pas rester seul dans l'erreur ??? non ?

A +

[pacmann]

T'as vraiment une dent contre MySQL...

In contrast to CHAR, VARCHAR values are stored as a one-byte or two-byte length prefix plus data. The length prefix indicates the number of bytes in the value. A column uses one length byte if values require no more than 255 bytes, two length bytes if values may require more than 255 bytes.

http://dev.mysql.com/doc/refman/5.0/en/char.html

... mais cette fois, c'est raté !

[SQLpro]

Mais cela dépend du moteur.. Donc il faudrait que tu me dise dans quel moteur tu a pêché cette info et si c'est pareil dans tous...

A +

[Waldar]

La longueur du char et du varchar existe et est stockée dans les deux types, sur deux octets.

En fait je n'ai pas été assez précis (je n'ai terminé le fil de la discution qu'hier) : un octet est utilisé pour stocker la longueur et un autre octet est utilité pour stocker si le champ est null.