Discussion :

[comme de bien entendu]

Bonjour,
Je vais faire des modifs dans une table extraite et la réintegrer ensuite via une requete update.

Si je fais une sauvegarde de cette table, pourrais je l'utiliser pour remplacer ma table si les données sont males intégrées lors de l'update ?

Autrement dit, si mon update se passe mal, pourrais je utiliser la sauvegarde de ma table, en vidant la table et en la réintegrant ensuite quelque soit les dépendances fonctionnelles avec les autres tables.

Di encore autrement pourrais faire un drop de la table "abimée" et ensuite un insert into (meme si il existe des dépendances fonctionnelles par ailleurs)
Ou dois je procéder autrement ?

Merci d'avance de votre retour.

[SQLpro]

La notion de "sauvegarde" pour une table n'a absolument aucun sens. Les notions d'import/export des données d'une table en ont un.

En effet, une base est un tout et du fait des règles d'intégrité déclaratives (contraintes SQL) et des règles d'intégrité fonctionnelles (déclencheurs par exemple) il existe de nombreuses interactions entre les tables.
De ce fait un export des données de la table suivi d'un import après modification externe de ces données ne peut, en aucun cas, garantir l'intégrité de la base après réintégration des données.

Autrement dit, vous devez faire ces modifications directement dans la base afin de préserver son intégrité !

A +

[comme de bien entendu]

Merci de votre réponse,

J'envisage de faire les modifications à l'exterieur de la base (plus facile dans Excel que dans la base pour 3000 champs à modifier) pour pouvoir faire ensuite un update en masse en faisant la jointure sur les clefs.
Seulement, je n'ai pas la possibilité de tester l'update ( mes clients ont négligé de mettre en place un environnement de dev...), de ce fait je me demandais si il y avait une astuce pour revenir en arrière au cas ou l'update foutait la grouille.

Sinon la solution serait elle de faire une sauvegarde totale de la base en dump pour pouvoir la remettre ensuite ?

Pas d'autre choix ?

[SQLpro]

Deux possibilité :
1) gérer une grande transaction explicite démarrant avant la première modification et se terminant par un COMMIT (validation) ou un ROLLBACK (annulation) après la dernière modif.
2) effectivement BACKUP RESTORE si les modification posent des problèmes.

À lire sur les transactions :
https://sqlpro.developpez.com/cours/sgbdr/#L3.2

A +

[comme de bien entendu]

Merci bien pour votre réponse documentée.