[Résolu] Comment mettre à jour les données ?

Bonjour à tous

Comme je l'ai déjà expliqué, mon site est actuellement géré de la façon suivante:
- les données variables sont gérées sur mon PC par l'intermédiaire de fichiers Excel
- ces données sont exportées sur le site sous la forme de fichiers XML

Le processus de modification est donc le suivant:
- je fais un ensemble de modifications sur mon PC
- quand elles sont cohérentes, je les exporte

Pour permettre de passer la main sur la gestion des données, j'ai décidé de mettre ces données dans une base MySQL. Cela permettra à tout autre personne disposant des droits d'accès ("administrateur") de modifier les données. Pour simplifier le problème, je suppose qu'il n'y aura qu'un seul administrateur à la fois qui se connecte, ce qui est une hypothèse acceptable dans le cas de ce site.

Mon problème:
si l'administrateur fait des modifications dans la base de données et que c'est cette même base de données qui est exploitée pour afficher les données aux utilisateurs, ceux-ci risquent de rencontrer une base incohérente pendant que l'administrateur est en train de faire des modifications. Ces modifications pouvant être longues (plusieurs heures quelquefois), un mécanisme de commitment me parait difficilement utilisable. Cela voudrait dire en pratique que l'administrateur ne peut pas interrompre sa mise à jour sous peine de devoir tout refaire.

Je pourrais bien entendu utiliser la base à l'usage exclusif de l'administrateur et fabriquer des fichiers XML lorsque l'administrateur considère ses modifications comme accomplies.
Une alternative aux fichiers XML: avoir des tables "admin" et des tables "users" et faire des mises à jours des tables "users" quand l'administrateur considère ses modifications comme achevées.
Ou bien deux bases de données et exporter la base admin dans la base users en fin de mise à jour.
Ou bien avoir un champ "temporaire" dans chaque table et faire un code (relativement complexe) pour que l'utilisateur ne voie pas les lignes "temp" mais que l'administrateur les voie de préférence aux autres.
Ou bien ...

Je suppose qu'il y a plein d'autres solutions pour traiter ce problème, aucune de celles auxquelles j'ai pensé ne me paraissant satisfaisante.

Pourriez vous me recommander une approche qui ait fait ses preuves?

Merci de vos conseils.

PapyJP a écrit :

Mon problème:
si l'administrateur fait des modifications dans la base de données et que c'est cette même base de données qui est exploitée pour afficher les données aux utilisateurs, ceux-ci risquent de rencontrer une base incohérente pendant que l'administrateur est en train de faire des modifications. Ces modifications pouvant être longues (plusieurs heures quelquefois), un mécanisme de commitment me parait difficilement utilisable. Cela voudrait dire en pratique que l'administrateur ne peut pas interrompre sa mise à jour sous peine de devoir tout refaire.

Hello
Alors moi je tique sur cette partie.
Il est anormale de travailler directement sur un environnement de production, tel que ton exemple.
Pourquoi ne pas monté un environnement de test pour éviter cela ?
avec un site "test", des données "test" sur une base de donnée de recette ?

S'il vous êtes dans l'impossibilité de travailler autrement et que l'administrateur est dans l'incapacité de faire "au plus vite" alors il faudrait automatiser cette tâche, et la lancer via un cron, la nuit.

Hello,

Je vois 3 possibilités pour une architecture d'amateur que je n'imagine que trop bien ne pas respecter ni le MVC, ni la POO.

1 : Tu rajoutes une colonne statut typée Int sur chacune de tes tables et tu définis ce statut à 1 quand modification en cours et 0 quand modification terminée (pourquoi int ? parce-que ton modèle peu avoir besoin d'autres états par la suite qu'un boolean). Et dans tes requêtes MySQL tu remontes ces valeurs à 0 et 1 mais dans le PHP avant la restitution tu fais si 1 afficher "modification en cours" et si 0 tu affiches le résultat réel.

2 : Tu rajoutes une table intermédiaire qui contient les modifications et tu n'affiches rien qui proviens de cette table à tes utilisateurs. Tu bascules le contenu dans ta vrai table quand c'est terminé.

3 : Si modification du site en cours par l'administrateur tu affiches un gros message "Modification du site en cours reprise estimée à 0:00 le 01/02/2019 ".

@+

Bon code.

@JENCAL je pense qu'il parle de modification de contenu de la base via un back office. Enfin j'espère

gray_magic a écrit :
@JENCAL je pense qu'il parle de modification de contenu de la base via un back office. Enfin j'espère

bah il parle de mise à jour de base de données ? peu importe le "comment" je pense qu'avoir différents environnement n'est pas une chose à prendre à la légère...

Bien!
En ce qui concerne les fichiers HMTL, CSS, JS, PHP, j'ai bien un site de tests sur lequel je teste les modifications avant de les reporter dans le site normal.
Pour ces fichus fichiers de données en XML, je les crée sur mon PC et je les transfère sur le site de tests, mais pour des modifications mineures, je les transfère directement sur le site normal.

Si je mets les données dans une database, je comprends que votre recommandation c'est de créer deux databases:
1) la database de tests que l'administrateur modifie et qui correspond à mes fichiers Excel actuels sur PC
2) la database normale dans laquelle on reporte les modifications quand elles ont été testées sur le site de test
AI-je bien compris que si je veux changer l'adresse d'une réunion ou rectifier une faute de frappe dans le nom d'une personne il va falloir exporter toute la database ?
Cette solution est la deuxième que j'ai listée ci-dessus.
Je suis un peu effrayé par les conséquences...

Salut Papy,

La nature des modifications n'est pas très claire. Il s'agit d'ajouter ou modifier des données ? Ou d'un changement dans le modèle de base de données ? Pour quelle raison les modifications peuvent prendre des heures (ça sent le besoin d'automatisation) ?

Il existe des outils pour gérer les changements apportés aux bases de données déjà en production. C'est le cas de sqitch ou flyway (il y en a d'autres évidemment). L'idée derrière ces outils, c'est de maitriser l'état dans lequel se trouve ta base de données en appliquant (ou retirant) de manière successive toutes les modifications sous la forme de scripts. Donc non, on manipule pas toute la base de données à chaque petite modification.

Dernier conseil (même si c'était le sujet de ton ancienne discussion), c'est franchement simple de gérer des données (peu importe la nature et la quantité) par le biais de formulaires. À ta place je me débarrasserais de ces fichiers Excel et XML.

Pour répondre partiellement à tes questions, voici les modifications que j’ai apportées à ce site aujourd’hui :

En premier lieu, ajouter dans le calendrier des activités la liste des œuvres de la prochaine répétition.

Ça consiste à entrer une liste d’identifiants de ces œuvres.
Pour cela, dans mes fichiers Excel je fais des copier/coller de certaines cellules. Pas question d’entrer ces identifiants à la main, ce serait la certitude de commettre des erreurs. Quand je ferai cela avec des formulaires de saisie, ça nécessitera des menus déroulants dynamiquement alimentés par de l’Ajax. On n’imagine pas en effet des menus déroulants contenant les centaines d’œuvres au répertoire de l’ensemble depuis 1999. Il faut donc un peu de programmation pour rendre cela ergonomique. Je sais comment faire, car c’est déjà comme cela que fonctionnent mes applis Excel, yapuka...

Ensuite, comme il y avait une œuvre nouvelle j’ai dû créer une série d’une dizaine de fichiers musicaux avec des outils appropriés, vérifier qu’ils étaient corrects, leur donner des noms permettant au programme de les retrouver, les charger sur le site, me rendre compte que les deux plus gros fichiers n’étaient pas correctement transférés avec WinSCP, mon outil préféré qui souvent ne parvient pas à charger de gros fichiers, les transférer sur le site de test avec FileZilla, vérifier que tout avait l’air cohérent et les mettre dans le site d’exploitation.
Vérifier également que le mécanisme qui modifie automatiquement les fichiers .cal qui permettent aux membres d’avoir les infos dans l’agenda de leur téléphone donnait bien le bon résultat, que la liste des fichiers musicaux était complète etc.
Tout cela pour UNE SEULE modification.

Ensuite j’ai dû retirer de la liste des membres (c‘est à dire changer leur statut) deux personnes qui ont participé au concert de la semaine dernière et ne reviendront plus chanter la suite du programme, supprimer leur adresse de la liste de diffusion, ce qui ne peut plus être automatique depuis que notre hébergeur a changé de politique dans ce domaine et finalement ajouter la photo d’un membre qui manquait dans la liste des membres.

Dans tous ces changements, il y a beaucoup de fabrication de fichiers (musicaux et images principalement) et de transferts de fichiers, le tout coordonné par quelques modifications dans la base de données.
C’est assez simple à faire avec des ficher sur Excel. Si je veux faire l’équivalent en ligne avec des formulaires de saisie ça demande pas mal de travail pour retrouver une ergonomie acceptable. C’est ce que j’ai l’intention de faire car il ne serait pas réaliste d’imposer à l’administrateur d’apprendre à utiliser les outils développés sous Excel. J’ai déjà un design approximatif de la partie « gestion des données vue de l’administrateur ». Ce que je cherche actuellement c’est comment mettre les données en question en exploitation.
Actuellement ça se fait par un programme qui ne prend que les données pertinentes aux besoins de gestion de l’affichage. Je pense pour le moment que c’est plus simple et efficace d’utiliser un processus de ce genre que soit utiliser une database commune avec tous les risques de manque d’intégrité que cela comporte, soit recopier à l’aveugle la totalité de la bases de tests.

J’ajoute que je n’ai aucune intention de perdre du temps à apprendre à utiliser des outils que je ne maîtrise pas. A mon âge c’est un investissement lourd que le peu de temps qui me reste à vivre ne me permettra pas d’exploiter, et par expérience je finis par me heurter aux limites des outils et à tout refaire moi même. C’est par exemple ce qui s’est produit avec jQuery: après quelques semaines d’essais, j’ai trouvé plus simple et plus efficace d’utiliser la librairie de fonctions que j’ai constituées depuis une bonne vingtaine d’années, avant même que jQuery n’existe.
Je ne recommanderais pas à d’autres personnes de faire de même bien entendu.

Okay, on laisse tomber les nouveaux outils. C'était plus à titre informatif au final. La bonne nouvelle c'est que dans ta situation, il s'agit uniquement d'ajouter ou modifier des données. Ça veux dire que tout peut s'effectuer par la biais de formulaires, et c'est le but au final si tu souhaites déléguer l'administration des données à quelqu'un d'autre non ?

Tu cites la certitude de ne pas commettre d'erreur en copiant-collant les identifiants de tes oeuvres, comme un étant un avantage à l'utilisation des fichiers Excel. En vrai, récupérer des identifiants déjà existants dans une base de données c'est encore plus simple et sûr qu'un copié-collé dans Excel, mais c'est pas la question. On retient rarement les identifiants des données qu'on manipule, on préfère utiliser des noms communs ou des descriptions. Où je veux en venir, c'est que tes futurs formulaires te demanderont de choisir parmi une liste d'oeuvres avec des noms ou des descriptions que tu connais, et tu laisses le code gérer les identifiants pour toi.

En vrai, je pense que le réel problème est un peu détourné. Si je te dis que ton application elle doit servir d'interface entre l'utilisateur et ta base de données, et que chaque formulaire nécessite les bonnes requêtes pour manipuler les données... tu me diras que tu le sais déjà. Du coup on connait l'architecture, on connait le flux des données, il manque quoi ? Juste la présentation. J'ai le sentiment que la seule chose dont tu as besoin de savoir, c'est comment créer un formulaire béton, ergonomique, responsive [ajoutez l'adjectif manquant] pour rendre la tâche de ton futur administrateur facile. C'est pas impossible à faire, et il manque pas de personnes compétentes ici pour t'aider.

Good night !

Merci de ta réponse

Bien entendu l’interface sera des listes déroulantes des titres des œuvres et pas leurs identifiants. Ça demande un peu de travail pour présenter les bonnes entrées dans ces listes pour éviter d’avoir des listes avec plusieurs centaines de lignes, mais ce n’est pas un gros problème.

Le point qui n’est pas clair pour moi c’est le processus de publication des données par l’administrateur.
Étape 1: il modifie ou crée des enregistrements dans la database et crée ou modifie des fichiers dans le système de fichiers.
Durant cette étape, qui correspond à ce que je fais actuellement sur mon PC, les modifications ne sont pas visibles par les utilisateurs.
Étape 2: il considère que c’est bon et publie ses modifications
La question est « comment ça se passe ? »
C’est cela l’objet de cette discussion.

Ce que je pense pour le moment, c’est avoir une database "admin" et une database "public" et faire une mise à jour des modifications de la première vers la deuxième. Ça me semble lourd comme processus et c’est pour cela que j’aimerais avoir l’avis de personnes qui l’ont déjà fait.

Oui, merci, c'est sans doute la bonne approche.
Ça signifie que l'administrateur sache gérer le workflow, ce qui n'est pas évident, mais un peu de réflexion et de design de ma part peuvent éviter de grosses bourdes, du genre ne pas accepter -- dans l'application de saisie -- des références à des objets qui n'existent pas encore, mais surtout mettre un warning dans le formulaire de saisie pour rappeler ce genre de contraintes, évidentes... quand on a déjà rencontré le problème.
Il est certain qu'étant à la fois le concepteur-réalisateur du site et le seul administrateur, je n'ai pas vraiment besoin de garde fou, surtout que je fais ça depuis près de 20 ans, les réflexes sont acquis.
Je vais partir sur un design de ce genre, on verra bien ce qui se passe, je ne manquerai pas de consulter les experts à l'occasion.
Je marque le sujet comme résolu... du moins pour le moment.
Modifié par PapyJP (23 Jan 2019 - 13:53)