PROGRAMMER DES COPIES DE TABLES SUR UNE BASE MYSQL
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
-
31 juil. 2005 à 13:06
cs_caviar Messages postés 329 Date d'inscription samedi 4 janvier 2003 Statut Membre Dernière intervention 29 mars 2015 - 29 sept. 2006 à 14:58
cs_caviar Messages postés 329 Date d'inscription samedi 4 janvier 2003 Statut Membre Dernière intervention 29 mars 2015 - 29 sept. 2006 à 14:58
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/32981-programmer-des-copies-de-tables-sur-une-base-mysql
https://codes-sources.commentcamarche.net/source/32981-programmer-des-copies-de-tables-sur-une-base-mysql
29 sept. 2006 à 14:58
faudrait y penser à l'export zip avec sauvegarde de la bdd sur le serveur direct ;)
cool !!!
@+
1 août 2005 à 14:01
Tout cela en automatique ?
Bon, d'accord, ca s'eloigne de la première source, j'admets... :)
1 août 2005 à 14:01
Tout cela en automatique ?
Bon, d'accord, ca s'eloigne de la première source, j'admets... :)
1 août 2005 à 12:37
1 août 2005 à 12:32
1 août 2005 à 11:55
1 août 2005 à 11:19
Hellodelu007 : ce script fait un CREATE... SELECT table par table, sans parallélisation... encore une fois, ce script est un système minimaliste qui ne prétend pas répondre à des besoins de taille professionnelle, mais simplement simplifier la vie des amateurs.
1 août 2005 à 10:07
1 août 2005 à 06:41
31 juil. 2005 à 14:32
a +
31 juil. 2005 à 14:27
1) je ne copie une table ligne par ligne, et je ne copie pas non plus une table dans une autre qui existerait déjà ; je fais un CREATE... SELECT pour chacunes DES tables à copier. Ma boucle est donc une boucles des tables et non une boucles des lignes.
2) je préfère de loin mon CREATE... SELECT que le INSERT... SELECT que tu proposes. INSERT est un peu plus rapide, mais il complique la tâche du webmaster, qui doit alors créer lui-même un clone de chacune des tables qu'il veut sauvegarder, et le re-créer à chaque modification de structure de la table d'origine.
CREATE fait lui-même le clone à chaque fois ; tout ce que le webmaster a à faire c'est de renseigner le nom de la table à copier et la fréqence de copie, le reste se fait tout. Comme c'est un script qui tournera au maximum une fois par jour, économiser quelques dixièmes de seconde ne présente pas un intérêt énorme...
3) tu parles de "multiples requêtes" dans la boucle. Il y a trois requêtes dans ma boucle : la première supprime un éventuel clone déjà existant ; la deuxième effectue la copie ; la troisième renseigne la nouvelle date de copie dans `sauvegardes`. La première et la troisième pourraient effectivement être sorties de la boucle, mais au détriment de l'atomicité des traitements...
... autrement dit, je pourrais faire un DROP table1_copie, table2_copie, etc. juste avant la boucle. Mais si qqch déconne au cours du traitement, par exemple si une table est trop grosse et que sa copie dépasse le temps d'exécution alloué par le serveur, j'ai perdu toutes mes sauvegardes ! (mon script actuel n'en perd qu'une)
De même, je pourrai faire un seul REPLACE INTO `sauvegardes` à la fin de la boucle, mais si le script est interrompu est cours de boucle, la date de màj ne sera renseignée pour aucune des tables.
Là encore, ce script n'est amené à tourner qu'au maximum une fois par jour, donc la performance est un objectif très secondaire par rapport à la sécurité, la facilité de maintenance, etc.
31 juil. 2005 à 13:06
si j'ai bien compris, tu prends une table que tu recopies dans une autre table dans ta boucle ?
Pourquoi ne pas faire une seule requête au lieu de faire de multiples requêtes dans ta boucle ?
Une requête à base d'INSERT INTO table(SELECT INTO autre_table champ,champ2)... ?
à moins que tu aies déjà tenté de le faire ;-)
a +