Fusionner deux entrées de table avec des colonnes uniques (MySQL)

Question

Je sais très bien que ça ne devrait jamais arriver. Jamais. Cependant, j'ai récemment commencé à travailler dans une entreprise dont la conception de la base de données ou la validation des entrées n'était pas des meilleures, et cette situation s'est présentée.

Il existe une table que nous appellerons "emplois "*. Les emplois ont une clé primaire, "ID". Le travail avec l'ID de 1 a beaucoup de données associées avec lui ; Cependant, stupidement, quelqu'un a dupliqué ce travail comme ID 2 (cela s'est produit environ ~500 fois jusqu'à présent). Toutes les informations des deux doivent être fusionnées sous l'identifiant 1 (ou 2, peu importe).

Les colonnes sont liées par une clé étrangère avec UPDATE : CASCADE et DELETE : RESTRICT. Elles ne s'appellent pas toutes jobs_id.

Est-ce que ma seule option (apparemment raisonnable) est de.. :

1. Changer l'id 1 en quelque chose dont je peux garantir qu'il n'est pas utilisé (2 147 483 647).
2. Supprimer temporairement la clé étrangère DELETE : RESTRICT
3. Supprimer l'entrée avec l'id 1
4. Mettre à jour l'id 2 en 2 147 483 647 (pour le lier à toutes les autres entrées)
5. Changer l'id 2,147,483,647 en id 2
6. Rétablir SUPPRIMER : RESTRICT

Étant donné qu'aucune partie du code n'effectue réellement une suppression (la restriction n'est là que par sécurité (quelqu'un qui modifie directement la base de données)), et que la mise à jour en cascade est maintenue, les données ne devraient pas être désynchronisées. Cela semble cependant désordonné.

Cela sera enveloppé dans une transaction.

Je pourrais écrire quelque chose pour itérer à travers chaque table (~180) et chaque colonne pour trouver certains noms / conditions, puis mettre à jour de 1 à 2, mais cela nécessiterait une maintenance lorsqu'une nouvelle table / colonne apparaîtrait.

Comme cela s'est produit à plusieurs reprises et que je ne vois pas de réécriture pour empêcher que cela se produise de sitôt, la "solution" (le pansement) doit être semi-automatique.

• pas le vrai nom de la table. Son identité a été déguisée pour qu'il (ou elle) ne soit pas victime d'intimidation.

J'apprécie toute contribution.

Answer 1

En supposant que vous savez comment identifier les enregistrements dupliqués, pourquoi ne pas créer une nouvelle table avec la même structure (peut-être sans les FK), puis parcourir en boucle l'original tout en copiant les valeurs dans la nouvelle table. Lorsque vous rencontrez une duplication, corrigez la valeur en écrivant dans la nouvelle table. Ensuite, laissez tomber l'original et renommez le temporaire en original.

Cela nettoiera la table, mais si les processus font encore des entrées en double, vous pouvez utiliser une clé unique pour limiter les dégâts à l'avenir.