Bonjour,
Je voudrais implémenter dans mon appli un système d'archivage "sélectif" des
données. Par exemple permettre à l'utilisateur d'archiver tous les documents
d'un client antérieurs à une date donnée. A votre avis, quel est le meilleur
moyen pour y arriver ? Est ce, par exemple, en créant toutes les tables
nécessaires vides en ensuite en recopiant les données une à une ou
existe-t-il un système plus pratique, notamment grace au langage sql ?
Faut-il envisager une gestion de répertoires dans lesquels on stockerait les
archives (mais dans ce cas, comment procéder avec une base relationnelle
comme MySQL) ? Par la même occasion, peut on raisonnablement envisager un
système de restauration ? etc...
Pour information, mon appli utilise une centaine de tables, bien sûr liées
entre elles par de multiples clés.
En somme j'aurais besoin de vos avis pour avoir un début de piste qui ne me
mène pas dans une impasse.
Merci à tous
ce que tu peux faire, c'est creer une base db_archive (sur le meme serveur que les données), et faire des requetes cross database :
create table db_archive.latable_2007 select * from latable where annee 07;
delete from latable where annee 07;
pour restaurer les données : insert into latable select * from db_archive.latable_2007
gg
Bonjour Oui c'est effectivement ce que je cherche à faire. Mais j'aurais voulu créer une autre base de données (par ex. base2007) pour ne pas multiplier les tables dans la base existante. Est ce que c'est possible par programmation ? et dans ce cas, les requetes "create table db_archive.latable_2007 select * from latable where annee 07" ne sont plus valide. Alors comment faire sans passer par des fichiers textes ?
Dans ce cas, j'essayerai :
Archivage :
create database archives2007;
create table archives2007.latable select * from baseprod.latable where annee 07;
delete from baseprod.latable where annee 07;
Restauration :
replace into baseprod.latable select * from archives2007.latable;
gg
I.G.LOG a écrit :
Salut,
ce que tu peux faire, c'est creer une base db_archive (sur le meme serveur
que les données), et faire des requetes cross database :
create table db_archive.latable_2007
select * from latable where annee 07;
delete from latable where annee 07;
pour restaurer les données :
insert into latable select * from db_archive.latable_2007
gg
Bonjour
Oui c'est effectivement ce que je cherche à faire. Mais j'aurais voulu créer
une autre base de données (par ex. base2007) pour ne pas multiplier les
tables dans la base existante. Est ce que c'est possible par programmation ?
et dans ce cas, les requetes "create table db_archive.latable_2007 select *
from latable where annee 07" ne sont plus valide. Alors comment faire sans
passer par des fichiers textes ?
Dans ce cas, j'essayerai :
Archivage :
create database archives2007;
create table archives2007.latable
select * from baseprod.latable where annee 07;
delete from baseprod.latable where annee 07;
Restauration :
replace into baseprod.latable
select * from archives2007.latable;
ce que tu peux faire, c'est creer une base db_archive (sur le meme serveur que les données), et faire des requetes cross database :
create table db_archive.latable_2007 select * from latable where annee 07;
delete from latable where annee 07;
pour restaurer les données : insert into latable select * from db_archive.latable_2007
gg
Bonjour Oui c'est effectivement ce que je cherche à faire. Mais j'aurais voulu créer une autre base de données (par ex. base2007) pour ne pas multiplier les tables dans la base existante. Est ce que c'est possible par programmation ? et dans ce cas, les requetes "create table db_archive.latable_2007 select * from latable where annee 07" ne sont plus valide. Alors comment faire sans passer par des fichiers textes ?
Dans ce cas, j'essayerai :
Archivage :
create database archives2007;
create table archives2007.latable select * from baseprod.latable where annee 07;
delete from baseprod.latable where annee 07;
Restauration :
replace into baseprod.latable select * from archives2007.latable;
gg
I.G.LOG
> Dans ce cas, j'essayerai :
Archivage :
create database archives2007;
create table archives2007.latable select * from baseprod.latable where annee 07;
delete from baseprod.latable where annee 07;
Restauration :
replace into baseprod.latable select * from archives2007.latable;
gg
Je vais essayer ça. Merci beaucoup pour cette idée
> Dans ce cas, j'essayerai :
Archivage :
create database archives2007;
create table archives2007.latable
select * from baseprod.latable where annee 07;
delete from baseprod.latable where annee 07;
Restauration :
replace into baseprod.latable
select * from archives2007.latable;
gg
Je vais essayer ça. Merci beaucoup pour cette idée
create table archives2007.latable select * from baseprod.latable where annee 07;
delete from baseprod.latable where annee 07;
Restauration :
replace into baseprod.latable select * from archives2007.latable;
le problème qui va se présenter: les index auto-increment ! Non ?!
Firetox
Bonjour,
"I.G.LOG" a écrit dans le message de news:49f1bc62$0$12646$
le problème qui va se présenter: les index auto-increment ! Non ?!
non puisque dans le select ils vont etre selectionnés sous mySQL pour conserver les autoIncrement il faut les envoyer dans l'insert sinon si on ne les envoie pas ils sont recalculés
Bon dev @+
Bonjour,
"I.G.LOG" <iglog@free.fr> a écrit dans le message de
news:49f1bc62$0$12646$ba4acef3@news.orange.fr...
le problème qui va se présenter: les index auto-increment ! Non ?!
non puisque dans le select ils vont etre selectionnés
sous mySQL pour conserver les autoIncrement il faut les envoyer dans
l'insert sinon si on ne les envoie pas ils sont recalculés
"I.G.LOG" a écrit dans le message de news:49f1bc62$0$12646$
le problème qui va se présenter: les index auto-increment ! Non ?!
non puisque dans le select ils vont etre selectionnés sous mySQL pour conserver les autoIncrement il faut les envoyer dans l'insert sinon si on ne les envoie pas ils sont recalculés
Bon dev @+
I.G.LOG
"Firetox" a écrit dans le message de news: 49f1c086$0$6188$
Bonjour,
"I.G.LOG" a écrit dans le message de news:49f1bc62$0$12646$
le problème qui va se présenter: les index auto-increment ! Non ?!
non puisque dans le select ils vont etre selectionnés sous mySQL pour conserver les autoIncrement il faut les envoyer dans l'insert sinon si on ne les envoie pas ils sont recalculés
Décidément incollable sur les bases de données ;-) Encore merci
"Firetox" <firetox@free.fr> a écrit dans le message de news:
49f1c086$0$6188$426a74cc@news.free.fr...
Bonjour,
"I.G.LOG" <iglog@free.fr> a écrit dans le message de
news:49f1bc62$0$12646$ba4acef3@news.orange.fr...
le problème qui va se présenter: les index auto-increment ! Non ?!
non puisque dans le select ils vont etre selectionnés
sous mySQL pour conserver les autoIncrement il faut les envoyer dans
l'insert sinon si on ne les envoie pas ils sont recalculés
Décidément incollable sur les bases de données ;-) Encore merci
"Firetox" a écrit dans le message de news: 49f1c086$0$6188$
Bonjour,
"I.G.LOG" a écrit dans le message de news:49f1bc62$0$12646$
le problème qui va se présenter: les index auto-increment ! Non ?!
non puisque dans le select ils vont etre selectionnés sous mySQL pour conserver les autoIncrement il faut les envoyer dans l'insert sinon si on ne les envoie pas ils sont recalculés
Décidément incollable sur les bases de données ;-) Encore merci
