Discussion :

[EPH69]

Débutant en SQL, et malgré maintes recherches, je n'ai pas réussi à trouver la solution à ce prb :

J'ai une table nommée modele composée des colonnes code_modele, nom_modele

Lorsque le nom_modele a des code_modele différents, j'aimerais les fusionner pour qu'il ne reste qu'un code_modele (et pas supprimer ces "doublons" car j'ai des informations de vente et d'achat sur chacun des modeles (ex:facture en cours ce qui m’empêche toute suppression)

ex:
code_modele nom_modele
1000555 lampo
1000159 lampo

Résultat attendu:
ne garder que le 1000159 et que mes informations vte/achat sur le 1000555 soient associées au 1000159

Merci de votre aide

[CinePhil]

Quel est le critère qui détermine que tu vas garder 1000159 et non pas l'autre ?

[EPH69]

Bonjour CinePhil,

Merci de t'intéresser à ce sujet.
En réalité aucun critère particulier. 1000159 était le premier code attribué à ce modèle, 1000555 ne devrait pas exister, il a été créé sans vérifier que le modèle Lampo existait déjà.

Sur les 2 codes, il y a des mouvements Achat / Vte et des factures en cours.

Dans l'attente de ta réponse ou complément d'info, je te souhaite de bonnes fêtes.

Re-

Autre solution si c possible :

modifier le code 1000555 en 1000159 si l'historique est conservé. Mais là aussi, je n'ai rien trouvé dans les tutoriels.

Slts

[CinePhil]

Donne la description complète de ta table.

[islamov2000]

Puisque les deux articles sont identiques, je propose de faire une petite
modification des données si et seulement si les informations qui concernent ces articles sont aussi indentiques pour ne pas avoir perdu l'historique.

Comment faire?

Il faut penser aux tables liées à la table en question.

[Rymaya]

Si j'ai bien compris vous avez :
ex:
code_modele nom_modele MontantA/V
1000555 lampo 200
1000159 lampo 500

Comme sortie vous voulez avoir

code_modele nom_modele MontantA/V
1000159 lampo 700

C'est bien ça??

[punkoff]

En réalité aucun critère particulier. 1000159 était le premier code attribué à ce modèle, 1000555 ne devrait pas exister, il a été créé sans vérifier que le modèle Lampo existait déjà.

Bonjour,

Si vous ne donnez pas une règle afin de pouvoir identifier quel code à priorité sur un autre code on ne pourra pas le deviner.

A partir de là le problème n'a pas de solution mise à part une reprise manuelle au cas par cas.

[EPH69]

En réponse à CinePhil, le script de la table en pj

[CinePhil]

Je ne vois aucune colonne de date ni de clé primaire basée sur une séquence (un code alphanumérique est une mauvaise clé primaire !), il va donc être difficile de décider quel code conserver plutôt que tel autre !

Surtout que les autres informations d'un même produit avec des codes différents peuvent être potentiellement différentes ; lesquelles conserver ?

Bref, un bel exemple de ce qu'il ne faut pas faire en matière de BDD relationnelle !
Surtout qu'il y aurait d'autres critiques à faire sur cette table !

[EPH69]

Cette table a été créée et livrée avec un logiciel commercial pour magasin de meuble. Les données ont été créées au travers de l'application.

En finalité, peut-on, même manuellement, au cas par cas, effectuer une fusion même si l'on doit perdre l'historique du modele que l'on ne conserve pas.

[CinePhil]

Comme le code est la clé primaire de la table, il est probable que ce code soit aussi référencé dans d'autres tables.

1ère étape : trouver tous les doublons.
Il faut pour cela définir quelles colonnes de la table vont déterminer les doublons. Est-ce seulement le nom du produit ? Ou au contraire peut-il y avoir plusieurs produits physiques avec un libellé identique mais différents par d'autres colonnes de la table ?

2ème étape : trouver toutes les tables qui référencent le code du produit.
Cela permettra de mettre à jour également les clés étrangères.

3ème étape : Se fixer une règle pour choisir le doublon à supprimer.
Soit le code le plus petit, soit le code le plus grand.
Attention, ceci peut avoir des conséquences sur les produits physiques ! S'il y a des produits physiques en magasin avec le code que vous allez supprimer, bonjour les dégâts ! Surtout s'il y a du code barre associé ; ça va être la panique à la caisse !

4ème étape : Fusionner les données des codes en doublon.
Il faut comparer les autres colonnes des doublons qui peuvent avoir des données différentes et choisir, au cas par cas ou selon une règle à établir, quelle information conserver. Si une colonne est vide pour un exemplaire du doublon et pleine pour l'autre, il est facile de copier la donnée existante. Mais si les deux exemplaires ont des valeurs différentes pour la même colonne, laquelle choisir ? Ce sera sûrement à décider au cas par cas. Le mieux est de sortir la liste des doublons avec les infos qui posent problème et de laisser le métier décider. Ils ont fait de la merde avec leur BDD, qu'ils assument un peu !

5ème étape : Supprimer les doublons devenus inutiles.
Il faut mettre à jour les clés étrangères avec le code conservé pour les lignes qui possèdent actuellement le code à supprimer.
Ensuite, on peut enfin supprimer les doublons devenus inutiles.

Se poser quand même la question sur les conséquences physiques d'une telle opération !
Si un client pose une réclamation sur un produit portant un code qui n'existe plus dans la BDD, que se passera t-il ?

Il faudrait, par précaution minimum, enregistrer la trace des correspondances entre anciens codes et nouveaux et bien briefer le personnel en charge de prendre en compte ce genre de problème.

Bon courage !