Discussion :

[Xt0ff]

Bonjour,

J'essaie de modifier une table en utilisant phpmyadmin. J'essaie juste de modifier la structure d'un champs d'un varchar 7 à un varchar 3 et de valider. Cela correspond à la requête SQL suivante:

Code :

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

ALTER TABLE `diplomatic_missions` CHANGE `hosting_country_id` `hosting_country_id` VARCHAR(3) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL;

Mais la modification ne se fait pas. J'obtiens le message d'erreur suivant:

Code :

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

1
2
 Erreur de requête:
#1025 - Erreur en renommant '.\embassies_dev\#sql-6a6c_141' en '.\embassies_dev\diplomatic_missions' (Errcode: 150 "Foreign key constraint is incorrectly formed")

Le truc, c'est que j'ai viré en apparence tout ce qui était clé secondaire et index. Il ne me reste plus qu'une clé primaire par table.

Quelqu'un saurait il pourquoi j'ai ce message d'erreur, et comment y remédier?

[Xt0ff]

Bon... J'ai trouvé une solution.
J'ai copié ma table. Phpmyadmin me demande à la copie si je veux ajouter les contraintes de clés étrangères. Normalement, j'en avais pas, mais pour être sûr, j'ai décoché le truc...
Sur la copie de ma table, j'ai bien pu modifier mon champs de varchar 7 à varchar 3.

[Artemus24]

Salut Xt0ff.

Y-a-t-il une raison de passer d'un varchar(07) à un varchar(03) ?

Le varchar se construit à partir de sa longueur puis ensuite la chaine de caractères.
L'occupation mémoire ne va pas changer !

Cordialement.
Artemus24.
@+

[escartefigue]

D'une part, choisir du varchar pour un longueur aussi petite que 3 ou 7 n'a que très rarement d'intérêt, le plus souvent, on gagnera à utiliser du char fixe, car le varchar présente certains inconvénients, notamment lors des mises à jour de contenu et aussi lors des comparaisons, qui pénalisent les performances comparativement au char fixe.
D'autre part, vu que la colonne est suffixée _id, on peut supposer qu'il s'agit de l'identifiant et donc de la clef primaire.
Auquel cas char comme varchar sont le plus souvent un très mauvais choix : le contenu de ce type de colonnes est rarement stable, or la stabilité des valeurs est primordiale pour une PK !

[Xt0ff]

Ah ok! Merci! Je ne savais pas.
Du coup je vais modifier ces varchar(3) en char(3) alors...
Char(3) car contient le code ISO 3166 des pays sur 3 caractères..., qui se trouve oui être la clé primaire de ma table "pays".
Je vais donc comme je disais modifier tout ca par des char au lieu de varchar... Merci!

[escartefigue]

Pour rappel, le varchar requiert 1 à 3 octets en préfixe de la colonne pour contenir la longueur effective. En l'occurrence, du varchar(3) c'est donc 1 octet de longueur + 3 octets de contenu, soit un octet de plus que du char(3).
Par ailleurs, la norme ISO 3166-3 ne contient que des valeurs sur 3 octets, du coup, outre les inconvénients techniques inhérents au varchar, le varchar est ici complètement inutile.

Enfin, attention, vu que la nomenclature ISO 3166 est externe à votre système d'information, rien n'interdit qu'elle évolue soit en contenu (un code pays qui change par exemple) soit en format (char(3) --> char(4) par exemple).
Ce faisant, la stabilité des valeurs n'est pas garantie. Quand des valeurs sont issues d'un système externe, il n'est pas recommandé de les utiliser comme PK, car, pour rappel, la valeur d'une PK doit être stable.
Il serait donc sage de définir une PK technique (auto_increment de type integer) et de positionner une contrainte unique mais non PK sur la colonne contenant l'actuelle PK.