peug
Messages postés232Date d'inscriptionmercredi 25 octobre 2000StatutMembreDernière intervention 5 octobre 2012
-
25 nov. 2008 à 18:25
LIBRE_MAX
Messages postés1402Date d'inscriptionmardi 1 mai 2007StatutMembreDernière intervention 7 octobre 2012
-
25 nov. 2008 à 23:04
Salut,
Je commence une appli avec un Base .MDB (ADO) mais je m'inquiète d'une chose. Mon client va d'année en année alimenté cette bdd. J'imagine même pas la taille dans 2 ans. Quelle solution existe pour archiver ? Tout en conservant toutes ses données ?
PCPT
Messages postés13272Date d'inscriptionlundi 13 décembre 2004StatutMembreDernière intervention 3 février 201847 25 nov. 2008 à 18:37
salut,
dur de te répondre.....
à première vue : une base de données?
plus sérieusement il y a 2 choses :
une base de données est faite évidemment pour grossir....
maintenant on choisi le type de base selon les informations (taille/poids) qu'on compte y mettre.
si tu estimes que la base va peser :
*+1Go par an, même pas la peine de penser à access...
*+300Mo par an? çà reste encore possible, bien que le mois de décembre (comme le service militaire) sera plus long et dur que les autres...
2 possibilités (cumulables) se proposent à toi :
*compacter régulièrement la base (une fois par semaine, ou par jour), codyx.org pour voir le code...
*faire un export et donc une nouvelle base de l'année précédente pour ne travailler sur une base ne contenant que l'année en cours. encore faut-il ne pas avoir besoin des infos de l'année précédente
après comme indiqué, çà dépend du poids, c'est un choix à faire normalement AVANT de coder...
et tu es mieux placé que nous pour estimer des data à écrire
++
<hr size="2" width="100%" />
Prenez un instant pour répondre à [sujet-SONDAGE-POP3-POUR-CS_769706.aspx ce sondage] svp
cs_Orohena
Messages postés577Date d'inscriptionvendredi 26 septembre 2008StatutMembreDernière intervention20 novembre 20104 25 nov. 2008 à 21:14
bonjour peug
Outre les solutions proposées par PCPT, je te propose celle-ci, qui part du principe selon lequel une base de données
Access peut travailler avec sa propre bdd (currentDb) mais aussi avec une ou plusieurs bases de données distantes. Les règles sont très simples.
1) créer une bdd code.mdb qui contient principalement ton code (plus facile à maintenir), et quelques paramètres
2) créer une bdd modele.mdb qui contient toutes tes tables vides, relations, requêtes...
3) Tous les ans, créer une nouvelle bdd, par exemple bdd2009.mdb, dérivée de modele.mdb
Cette architecture semble possible dans ton cas, puisque ton appli n'est pas encore opérationnelle. Elle serait beaucoup plus compliquée pour une application existante.
Avec ce système :
- aucune bdd ne grossira indéfiniment,
- tu pourras archiver ou garder en ligne les mdb à ta convenance
- tu n'auras à sauvegarder régulièrement que le mdb des données de l'année en cours
LIBRE_MAX
Messages postés1402Date d'inscriptionmardi 1 mai 2007StatutMembreDernière intervention 7 octobre 20126 25 nov. 2008 à 23:04
Salut,
En partant du principe qu' on ne travaillera que sur la base de l' année en cours (et donc archivage) et en combinant les deux solution proposées:
* faire un export et donc une nouvelle base de l'année précédente pour ne travailler sur une base ne contenant que l'année en cours. encore faut-il ne pas avoir besoin des infos de l'année précédente.
-Exporter oui mais en la duplicant (qui servira donc de modèle) puis ne comserver qu les données des tables fixes et quelques tables de base(âr exemple : fichier clients, Fournisseurs, Articles,Personnel...etc...) qui sont en général légérement évolutifs.
Vider ensuite toutes les tables qui sont destinées à des écritures.
(par exemple: achats , ventes, reglements...etc)
Ainsi la structure de la base sera maintenue (relations et autres) tout en l' allègeant du poids des ans !
Sachant bien que l' application doit pouvoir pointer vers l' une ou l' autre des années archivées selon le choix de l' utilisateur et suivant les règles et la stratégie de l' administrateur(verrouillage/déverouillage et cloture des exercices).