Discussion :

[justine91]

bonsoir, je reviens encore vers vous
J'aimerai savoir si il est possible de stocker un état dans ma fiche
Et donc de consulter mon état quand j'en aurai l'envi
Merci
Justine

[marot_r]

Qu'est-ce qu'une fiche ?

Est-ce que tu veux une image du rapport au moment où tu l'as regardé la 1ère fois ?

Ou peut-il être recalculé et affiché avec les données du moment ?

A+

[justine91]

désoler je m'exprime mal, (je suis débutante)
Ce que j'appelle fiche c'est un formulaire en colonne simple
dans mon formulaire en colonne simple j'ai un bouton valider, annuler et imprimer état
J'aimerai si c'est possible enregistrer mon état dans ma fiche (formulaire en colonne simple)
comme ça quand je modifierai ma fiche, j'aurai une sauvegarde de ce qu'il y avait avant

Justine

[Tofalu]

Bonjour

Le sujet est plutôt complexe.

J'y vois deux pistes :

- Concevoir l'historisation des données (cela sous-entend de revoir le modèle conceptuel, de traiter la notion de date)
- Stocker simplement un cliché de l'état à l'instant T (comme par exemple : enregistrer les états sous forme de PDF)

La première solution est plus complète mais aussi beaucoup plus complexe. Un client n'a plus un nom, ni une adresse mais un nom à une date J (cas des changements de nom, mariages, divorces). Le client n'habite plus à une seule adresse mais à une adresse à une date J (déménagement). Cela rend les requêtes plus difficile à écrire et moins performantes dans la mesure où il faudra rajouter à chaque fois le filtre de la date.

[ClaudeLELOUP]

Bonjour Justine, René, Christophe et les autres, s’il en est,


J’arrive peut-être avec de la moutarde après le dessert, mais s’il s’agit simplement d’archiver des états pour les consulter éventuellement à l’avenir, je créerais une version PDF de l’état avec PDFCreator (logiciel gratuit) : les documents sont automatiquement horodatés et stockés dans un répertoire au choix.
Donc un bouton « PDF » en plus des trois actuels.
Refais-moi signe si la solution te convient, je t'aiderai volontiers pour le code.

[Tofalu]

La réponse n'est pas forcément aussi simple.

Elle doit se faire en fonction de la volumétrie, des fréquences des modifications, de la volonté de pouvoir faire des recherches sur les données.

- Une base de données de 1000 clients avec un PDF de 1Mo, cela fait déjà 1Go de fichiers.

- Ensuite, imaginons des clients attachés à une agence et qu'il y ait changement d'agence. Est-ce que cela ne va pas être perturbant pour l'utilisateur que le programme se mette à régénérer des centaines d'états ?

- Comment rechercher les clients qui dépendait de l'agence de Lyon mais qui maintenant sont rattachés à Aix en Provence ?

- S'agissant de fiche produits pouvant provenir de plusieurs fournisseur, est-il judicieux de réimprimer toutes les fiches produits à chaque changement de dénomination commerciale ?

Quid de l'accès des données directement depuis l'explorateur de fichiers ? Comment garantir la sécurité, l'intégrité et la cohérence ?

Des fichiers peuvent être supprimés ? Que va faire le programme de fichiers malencontreusement renommés ?

[ClaudeLELOUP]

Christophe,
PDFCreator, c’est une imprimante qui produit un fichier PDF au lieu de papier.
J’ignore de quel genre d’états Justine nous parle, mais pour fixer les idées, le PDF d’un état d’une page occupe moins de 10 kilooctets… et 300 pages environ 1 250 kilooctets !
Le nom des PDF est préfixé de la date/heure, c’est donc tout facile de retrouver « le » PDF de l’époque.

[Tofalu]

La taille du fichier généré dépend de son contenu (images couleurs, qualité, nombre de pages)

Stocker des données sous forme d'état ou de document, c'est l'inverse du processus qui est en général la raison du passage à un SGBD : remplacer ces centaines de feuilles de calculs Excel par une solution plus robuste qui permette recherche et cohérence des données.

Il ne me semble pas, que s'agissant d'une base de données, nous puissions raisonnablement faire l'impasse sur l'intégrité et la cohérence. Car le risque est bien là : qu'un fichier soit supprimé ou renommé sans que l'application ne le sache.

[ClaudeLELOUP]

Christophe,

Je ne veux certainement pas polémiquer avec toi : mon niveau technique ne me le permet pas et je ne suis pas un professionnel de l’informatique.
J’ai cru comprendre que la question posée par Justine consistait à garder sous le coude une copie de l’état (autre que papier) au cas où.

Il ne me semble pas, que s'agissant d'une base de données, nous puissions raisonnablement faire l'impasse sur l'intégrité et la cohérence. Car le risque est bien là : qu'un fichier soit supprimé ou renommé sans que l'application ne le sache.

Je crois que c’est ici hors du propos : quand l’état a été imprimé (sous la forme papier ou PDF), il continue sans vie : à l’abri dans un coffre, à la poubelle, voire falsifié… l’application n’a plus de prise sur lui, ce n’est plus son domaine de responsabilité.

[justine91]

Bonjour
je vous remercie pour toutes vos réponses
J'ai résolu le pb d'une autre manière
Cordialement
Justine

[ClaudeLELOUP]

Ben, vous voyez René et Christophe, il y avait une autre solution...