Modification valeur enum & perte de données

La question est pratiquement contenue dans le titre:

J'ai une table qui contient un champ enum('Pomme','Poire','Orange','Banane').
Une certain nombre d'enregistrements ont la valeur 'Poire'.

A la demande des utilisateurs, je remplace 'Poire' par 'Prune' avec un Alter. Tous semble bien ce passer et je crois avoir remplacé à la volée toutes les valeur 'poire' par 'prune'.8O Que néni, toutes les valeurs poires ont disparue, mais ne sont pas remplacées par 'Prune' !!!

Une explication serait bienvenue.

Merci
---------------------
MySQL 5.0.15

Quelle requête a commis cette hécatombe ?

Celle-ci

Code:

---

ALTER TABLE `ma_table` CHANGE `Type_Fruit` `Type_Fruit` ENUM( 'Pomme', 'Prune', 'Orange', 'Banane', 'Cerise' ) NULL DEFAULT NULL

---

Alors qu'avant les valeur de Type_Fruit étaient ENUM( 'Pomme', 'Poire', 'Orange', 'Banane', 'Cerise' )

J'ai du récupérer avec une moulinette toutes infos depuis une sauvegarde :(

Si tu as une idée de la cause, je suis preneur car je n'aimerai pas que cela se reproduise. J'ai réussit à refaire la même manip, le résultat est le même. Donc, il ne s'agit pas d'un aléa passagé :mouarf: d'une grêve ou d'un volonté délibérée et temporaire du serveur de m'emmer...:mrgreen:

En lisant ton problème cet après-midi, je me suis demandé ce qu'il se passait :
- si on essaie d'entrer une valeur ne figurant pas dans l'énumération
- si on change l'énumération et qu'il y a déjà des valeurs

Tu es dans le second cas et tu as la réponse !

MySQL nous dit :

Citation:

---

Si vous insérez une valeur illégale dans une énumération ENUM (c'est à dire, une chaîne qui n'est pas dans la liste de valeurs autorisées), la chaîne vide est insérée pour représenter une erreur. Cette chaîne peut être distinguée d'une chaîne vide 'normale' par le fait que cette chaîne à la valeur numérique 0.

---

En changeant l'énumération, toutes les valeurs existantes ne satisfaisant pas la contrainte d'énumération ont été mises à blanc !

Moralité : Eviter d'utiliser le type ENUM pour des choses qui peuvent changer, comme c'est le cas pour tes fruits.
ENUM irait bien pour une colonne 'sexe' par exemple : ENUM('male', 'femelle', 'inconnu').
Pour le reste, il est généralement préférable de faire une table externe et de mettre une clé étrangère. L'avantage est que si tu décides de remplacer le type 'poire' par 'prune', tu ne le changes que dans la table de référence et la clé étrangère reste identique. Si tu veux ajouter le type 'prune' et décider que toutes les lignes qui étaient de type 'poire' deviennent des 'prune' tu changes la clé étrangère.

Merci pour ta réflexion à ce sujet.
Je comprends bien ce qu'il s'est passé maintenant.

Mais je ferais 2 remarques bien distinctes:

1/ pour ce qui est d'utiliser des tables externes avec des clef etrangères, j'en fais déjà usage bien entendu ;). Mais dans le cas de cette base qui comme tu l'aura compris (ou pas d'ailleurs) n'a rien à voir avec les fruits et légumes. Une des tables qui est utiliser est un descriptif techniques d'un matériel complexes de pièces détachées. Si je devais utiliser des tables externes à chaque fois que j'ai des choix multiples pour des valeur de champ, j'aurais pratiquement autant de tables que de champ.
Exemple: table1 champ type_moteur : valeurs "Dupond, Schneider, Beringer". En général ces valeurs sont fixes.

J'ai fait le choix arbitraire de créer des tables à partir du moment ou il y a plus de 20 choix possibles.

2/ En relisant le manuel MySQL, je me suis laissé abusé par le fait que les valeurs sont stockées sous formes numériques dans la base, alors que les valeurs elles même ne le sont que dans la description de la table.
Je me suis dit, si je change une des valeurs, elles changeront toutes. GRAVE erreur !!
Ce type de changement ne m'avait jamais été demandé, à l'avenir, voici la solution que je propose:

- créer la nouvelle entrée dans l'ENUM concerné
- Faire une requête pour déterminer tous les enregistrements concernée
- les mettres à jour avec la nouvelle valeur
- Supprimer l'ancienne.

J'espère que nous nous sommes compris.

A+

Riete