[Résolu] Saisie de données dans une base de données

Bonjour à tous
La base de données du site de mon association musicale comporte 6 tables principales:
- la table des membres
- la table des évènements (répétitions, concerts, réunions, etc)
- la table des lieux où se tiennent ces évènements
- la table des auteurs des œuvres au répertoire
- la table des œuvres
- la table des programmes (liste des œuvres au programme d'un concert par exemple)

Pour des raisons historiques, la saisie des données se fait de la façon suivante:
Ces tables se trouvent dans des fichiers Excel sur mon PC et je les exporte sous forme de fichiers XML que je copie par FTP, les fichiers XML étant générés par un programme écrit en VBA/Excel.
Ce mécanisme fonctionne de façon satisfaisante depuis la création du site, il y aura bientôt 20 ans.

Le problème est que ça ne peut fonctionner que si la personne qui gère le site connait parfaitement la façon dont il faut saisir les données et est en mesure d'effectuer la maintenance le programme VBA/Excel. En d'autres termes il m'est très difficile de passer la main à une autre personne.

Je désirerais donc supprimer l'étape Excel et effectuer la saisie et la modification des données sur le site lui même, au moyen de programmes écrits en PHP (et Javascript pour la partie client).

Auriez vous déjà réalisé un programme de ce genre? Avoir un modèle me permettrait de limiter le nombre de cycles essais/erreurs qu'on est contraint de subir dans ce genre de développement.

Merci de votre aide

Bonjour,

Tu fais des formulaires html dont les input recevront les valeurs à modifier.

Dans le formulaire, l'attribut "action" contiendra le nom d'un script php qui s'exécutera côté serveur. Si l'attribut method du formulaire vaut "post" (ce qui est souhaitable), ce script récupèrera les données des formulaires dans le tableau php $_POST[], et les insérera dans ton fichier XML.

Code assez trivial qui ne devrait pas te poser de problème : le script php regarde le contenu de $_POST[], modifie le XML (y a des fonctions en php pour ça), génère une page html pour répondre à l'utilisateur que tout va bien, et puis voilà.

Amicalement,

Oui, ça c’est bien sûr la techno à utiliser et je vois mal du reste comment on pourrait faire autrement. Je vais essayer d’être un peu plus précis dans la suite de la discussion je ferai cela demain.

Un avant goût du problème:
voici une saisie d'écran d'un bout de la page Excel qui sert à la gestion de la table "calendrier"

Cette page fait actuellement plus de 1300 lignes et une douzaine de colonnes.
Il n'est pas question de faire un formulaire de cette taille!
Par ailleurs si je veux ajouter une colonne, c'est très facile à faire ajouter la colonne, y mettre des infos, modifier le code ExcelVBA et le code PHP, ça prend une petite heure tout au plus.
Faire cela en remote, c'est une autre paire de manches...

Bonjour,

Ton formulaire est évidemment destiné à ne modifier qu'une seule ligne à la fois. On suppose que le reste est déjà en place.

Amicalement,

PS: au final, tes données sont dans un fichier XML ou dans une base de données ?

PapyJP a écrit :
Il n'est pas question de faire un formulaire de cette taille!

C'est tout à fait envisageable sans que cela soit un formulaire géant. Il suffit de faire une page exhaustive avec un système qui offrirait la possibilité de ne modifier qu'une seule ligne au clique.

Ou sinon une page listant uniquement les musiques, avec un petit lien sur chaque item renvoyant à une page dédiée affichant toutes les infos. Cette page comporterait le descriptif complet de chaque morceau ainsi que la possibilité de les modifier.

Tout cela uniquement à l'aide de bonnes requêtes MySQL.
Modifié par Olivier C (05 Jan 2019 - 10:37)

Merci de vos réponses
Je pense nécessaire de vous en dire plus sur ce site.

La "Base de données":
Par "base de données", il faut comprendre un ensemble de fichiers organisé de telle manière il soit facile d'écrire des programmes qui naviguent dans ces fichiers et retrouver les informations intéressantes.
Pour le moment, je n'ai pas fait appel à un SGBD (système de gestion de base de données), je me suis fait mon propre système de gestion, ce que mon passé de concepteur et développeur de système d'exploitation m'a permis de faire sans difficulté.
Je n'exclus pas de migrer la petite partie de ce mécanisme sous MySQL, mais dans ce cas précis cela ne me paraît pas intéressant. J'ai passé les 10 dernières années de ma vie professionnelle chez le plus grand fournisseur de SGBD, je n'ai pas de problème avec cette techno, mais je sais comment c'est fait, c'est sans doute cela qui me fait dire que je n'ai pas besoin de cette artillerie lourde pour un système aussi simple.

Comment sont organisés ces fichiers:
- la base de donnée des membres de l'association comprend une trentaine d'entrées, avec peu d'information pour chaque membre:
Nom, prénom, pupitre, téléphone, courriel, éventuellement adresse postale pour ceux qui le veulent, et les "sous-groupes" auxquels les gens appartiennent, particulièrement ceux qui sont membres du conseil d'administration. (les mots de passe sont gérés à part)
Ces données sont dans un fichier XML qui est lu quand un membre se connecte et produit des objets "membre". Par coquetterie de techie j'en profite pour les indexer, quoiqu'une recherche bêtement séquentielle dans une table de 30 entrées ne soit pas très consommatrice de CPU.
- il en est de même pour ce qui concerne la plupart des autres objets: lieux, auteurs, etc.
A chaque fois il n'y a que quelques informations par entrée et elles sont indexées par un identifieur unique. Aucun besoin de faire des recherches par autre chose que cet index.

Les fichiers sont organisés dans un système de fichiers dont les nœuds sont les identifieurs.
Pour les images, par exemple, la vignette représentant Jean-Sébastien Bach se trouve dans https:/www.alma-musica.net/images/auteurs/Bach.jpg l'affiche du concert du 18 janvier 2019 se trouve dans https://www.alma-musica.net/images/posters/C20190118.jpg car l'identifieur de ce concert est "C" comme concert suivi de la date.
- pour les partitions, c'est de la même façon organisé avec le même mécanisme:
https://www.alma-musica.net/html/partitions/Bach/Christ-lag.pdf est la partition de la cantate de Jean-Sébastien Bach intitulée "Christ lag in Todes Banden"

La description de ce même auteur dans le fichier authors.xml est

<author ID="Bach" link="http://agora.qc.ca/mot.nsf/Dossiers/Jean-Sebastien_Bach">
    <name>
        <first-name>Jean-Sébastien</first-name>
        <last-name>Bach</last-name>
    </name>
    <dates>
        <birth>1685</birth>
        <death>1750</death>
    </dates>
</author>

La description de la cantate en question se trouve dans le fichier works.xml

<work ID="Bach_ChristLagInTodesbanden" path="Bach/Christ-lag" performed="2012-06-09">
    <title>Christ lag in Todesbanden</title>
    <author>Bach</author>
    <choir>Choeur</choir>
    <instrument>Orgue</instrument>
    <work-doc name="default" file="Christ-lag"/>
</work>

On voit que la dernière fois que cette œuvre a été jouée dans un de nos concerts est le 9 juin 2012. Cette information est produite lors de la mise à jour de la table des programmes de concert, ce qui évite de la rechercher dynamiquement, comme on le ferait sans doute avec un SGBD relationnel. C'est ce genre de petites choses qui permet au système d'être efficace.

Je pense que cela doit être assez clair.

Revenons maintenant à la partie sur laquelle je me focalise actuellement:
comment saisir les données en remote d'une façon qui ne soit pas trop pénalisante par rapport à la saisie sous Excel.
Pour l'instant, voici ce que j'envisage de faire, mais justement la raison pour laquelle j'ai ouvert cette discussion c'est obtenir des avis de personnes qui ont déjà fait ce genre de choses.

Pour les membres, comme il n'y en a qu'une trentaine, je peux afficher la table, cliquer sur un nom, ouvrir un formulaire et le remplir. Cette fonctionnalité existe déjà pour permettre à chacun de mettre lui-même à jour ses informations.
De même il suffit d'un bouton + pour ouvrir un formulaire de création et - pour archiver le membre. En général je ne le détruis pas tout de suite car nous avons fréquemment des aller et retour de membres. Je leur garde le droit d'accès à la partie privée du site, signifiant qu'ils seront les bienvenus.

Pour les auteurs, même mécanisme. Comme ils sont plus nombreux (200 actuellement) je fais 26 boutons et j'ouvre la liste par lettre initiale.

Pour les œuvres (il y en a plus de 500 actuellement) je fais une indirection par la table des auteurs et je fais de même.

La table des "programmes" est un peu plus délicate à gérer, mais plus du côté logique de l'application que du point de vus saisie proprement dite. Il faut en effet saisir d'abord l'auteur et choisir l’œuvre dans une liste déroulante. Rien de bien compliqué à faire en AJAX.

Le casse tête c'est le calendrier.
Il contient actuellement la liste des activités depuis octobre 19999 !!!
Je pense indexer par "saison" et afficher une saison à la fois, sachant que chaque saison comporte une centaine d'évènements, ce qui est encore beaucoup pour un formulaire de saisie.
Je vais donc les afficher sous la forme d'une table qui ne montre qu'un seul mois avec un bouton pour montrer/cacher le contenu du mois et
- soit ouvrir un formulaire de saisie par un clic sur la ligne à modifier/ajouter
- soit faire de la saisie en ligne. Je sais que c'est faisable mais que ça marche plus ou moins mal selon les navigateurs. J'ai fait un essai il y a quelque temps et j'ai laissé tomber.
Votre avis?
Modifié par PapyJP (05 Jan 2019 - 11:54)

Bonjour,

Bah, SGBD d'urgence.

Amicalement,

parsimonhi a écrit :
Bonjour,

Bah, SGBD d'urgence.

Amicalement,

Pour mois ce serait plutôt "SGBD normal".
Du temps où j'étais étudiant on parlait des SGBD-R (relationnel) comme d'une technique prometteuse, mais ça ne tournait qu'en labo. Il fallait des espaces de disques énorme (en gros un SGBD-R a besoin du double de la taille disque) des mémoires énormes (ça ne marche bien que si au moins tous les index sont en mémoire) et un CPU ultra rapide (par rapport à ce qui se faisait à l'époque) pour faire marcher le bouzin.
Donc en pratique il fallait faire sans, et on faisait cela très bien!
Ce n'est que vers le milieu des années 1980 que le prix de la techno a suffisamment baissé pour que ce soit utilisable en pratique et qu'on retrouve des BDD-R dans un engin aussi petit qu'un GPS. C'est l'un de mes anciens patrons qui a fondé la filiale française d'Oracle, que j'ai rejoint quelques années plus tard (j'ai attendu qu'il soit parti...) et j'y ai retrouvé de nombreux collègues.
Mais tout ça c'était il y a très longtemps... souvenirs, souvenirs...
Modifié par PapyJP (05 Jan 2019 - 12:18)

Bonjour,

Y a pas besoin de mettre en place des trucs fumeux évidemment.

Un système classique mySQL ou MariaDB ou n'importe quoi d'autre. Ton hébergeur a surement ça en magasin, avec mise en place en 2 ou 3 clics.

EDIT: note qu'on n'est plus en 1980. On n'est plus à l'époque où le système d'exploitation d'un ordi devait tenir sur une disquette de 512Ko. Tout est SGBD-R de nos jours.

Amicalement,
Modifié par parsimonhi (05 Jan 2019 - 12:43)

Bien sûr que j'ai MySql chez mon hébergeur.
Mais pour quoi faire?
Je pourrais:
option 1: reconstituer les fichiers XML par des requêtes ?
option 2: aller chercher les infos des objets PHP dans la DB au lieu de les rechercher dans les fichier XML ? ça veut dire réécrire l'essentiel de mon code, avec les bugs afférents à une réécriture, pour ne gagner rien en perf, en temps...

Je le ferai peut être plus tard pour que la personne qui reprendra le site un jour se retrouve confortable avec une techno qu'il connaît, quoique je ne crois pas qu'une personne qui est capable de reprendre un site où le DOM est géré en JS ne soit pas capable de gérer des fichier XML en PHP.

Pour l'instant, mon problème c'est la saisie des données en remote au lieu d'Excel. Que je les mette dans des fichiers XML ou une DB c'est sans grande importance.
Modifié par PapyJP (05 Jan 2019 - 14:02)

Bonjour,

Bon, admettons que tu gardes ton fichier XML.

Tu peux utiliser les fonctions simpleXML de php.

Pour mettre à jour une ligne parmi d'autre :
1) tu lis ton fichier XML avec par exemple la fonction simplexml_load_file(),
2) tu bricoles pour y récupérer les données correspondant à une "table" (tu récupères l'ensemble des lignes). Il y a des fonctions dans php pour ça.
3) tu génères en php un grand tableau html avec sur chaque ligne les données d'une ligne de ta table, et dans la dernière colonne, tu mets un bouton "Edit" qui fait partie d'une <form> contenant, outre le bouton "Edit", des input hidden contenant les valeurs de chaque champ de ta ligne. L'action de la forme t'envoie vers une autre page qui sera un formulaire pour éditer cette ligne-là.
4) tu fabriques ton autre page en php qui contiendra ton formulaire pré-rempli (avec les valeurs récupérées de la page précédente), et sur validation de celui-ci, tu mets à jour avec un script php ton fichier XML (avec les fonctions de simpleXML).

Tu peux ajouter d'autres colonnes, avec un bouton "Supprimer" par exemple, et qui fonctionnera sur le même principe.

Enfin, pour créer une nouvelle ligne au tableau, tu peux en début de page ajouter un bouton "Créer", qui lancera un formulaire vierge permettant de saisir les valeurs des champs pour une nouvelle ligne.

Rien que du très basique dans tout ce fonctionnement : manipulation d'un fichier XML en php, génération d'un grand tableau à partir des données du XML avec des boutons sur chaque ligne permettant de déclencher une ou des actions concernant la ligne en question.

Amicalement,
Modifié par parsimonhi (05 Jan 2019 - 14:54)

parsimonhi a écrit :
3) tu génères en php un grand tableau html avec sur chaque ligne les données d'une ligne de ta table, et dans la dernière colonne, tu mets un bouton "Edit" qui fait partie d'une <form> contenant, outre le bouton "Edit", des input hidden contenant les valeurs de chaque champ de ta ligne. L'action de la forme t'envoie vers une autre page qui sera un formulaire pour éditer cette ligne-là.
4) tu fabriques ton autre page en php qui contiendra ton formulaire pré-rempli (avec les valeurs récupérées de la page précédente), et sur validation de celui-ci, tu mets à jour avec un script php ton fichier XML (avec les fonctions de simpleXML).

Voilà, c'est ce que je disais tantôt, en plus explicite ici. Après, que la techno s'appuie sur MySQL, XML ou autres fichiers JSON... qu'importe.
Modifié par Olivier C (05 Jan 2019 - 15:44)

Bonjour,

Je ne vois pas bien ton inquiétude pour l'utilisateur.

Il choisit (dans une bête page avec des liens, disons un lien par "table", la liste des "tables" pouvant être extraite de ton XML automatiquement) une "table" à modifier. Le serveur lui renvoie une page avec la liste des lignes contenues dans la "table" qu'il a choisie, lignes qui sont extraites de ton XML. Il en choisit une à modifier en cliquant sur un bouton "Modifier". Une autre page apparait avec un formulaire permettant de modifier la ligne en question.

Y a quoi de compliqué là-dedans ?

Amicalement,

Bonjour,

Olivier C a écrit :

Voilà, c'est ce que je disais tantôt, en plus explicite ici. Après, que la techno s'appuie sur MySQL, XML ou autres fichiers JSON... qu'importe.

Tout à fait d'accord.

Amicalement,

Mon inquiétude pour l'utilisateur c'est de lui présenter un truc dans lequel il faut faire de nombreuses actions pour parvenir à un résultat.
Ouvrir des formulaires, les remplir, les refermer, et cela ligne à ligne, c'est beaucoup moins pratique que de faire des copier/coller dans une feuille Excel, d'avoir un code VBA qui "devine" ce que tu veux faire, etc.
Certes je sais faire en JS + AJAX tout ce que je fais actuellement en VBA, et c'est bien ce que j'ai l'intention de faire, mais c'est du boulot, et avant de m'y lancer je voulais savoir ce que d'autres font.
Dans les forums du genre de celui ci je n'ai pas trouvé d'exemple de personnes qui remplissent une BDD (R ou pas). C'est apparemment tellement trivial qu'on en parle jamais.
La seule chose qui ait l'air documentée, c'est l'utilisation de phpMySQL, et franchement c'est une telle régression pour l'utilisateur par rapport à ce que je fais actuellement sous Excel qu'il ne saurait en être question.

Je vais donc me lancer dans ce que j'envisageais de faire avant d'ouvrir cette discussion.
Je vous ferai part de l'avancement et vous demanderai éventuellement votre avis sur des points délicats que je pourrais rencontrer.

Comme je l'ai dit à maintes occasions, ce forum est un bon endroit pour échanger. Il remplit le manque de machine à café entre collègues pour un retraité.
Modifié par PapyJP (07 Jan 2019 - 08:47)

Après deux jours de réflexions, j'arrive à la conclusion suivante:

Pour qu'elle soit ergonomique, la saisie des données a besoin de pouvoir accéder à l'ensemble de la base de données. Par exemple la saisie d'un évènement dans le calendrier nécessite
de pouvoir accéder:
- à la table des évènements déjà saisis, de façon à proposer à l'utilisateur des valeurs déjà utilisées dans le passé
- à la table des lieux auxquels se sont tenus d'autres évènements, avec la possibilité de créer un nouveau lieu pendant la saisie d'un évènement à un lieu non encore répertorié
- à la table des membres de l'association pour le cas où une réunion se tient au domicile de l'un deux
- à la table des œuvres au programme pour pouvoir indiquer quelles œuvres sont au programme de cet évènement.

Si je fais la saisie en Excel, la base de données est directement accessible, un ensemble de fichiers Excel constituant une base de données, et c'est ce que je fais actuellement.
Depuis Excel, il est trivial de générer des fichiers XML, de faire un upload de ces fichiers sur le serveur. Le code du serveur ne sert qu'à afficher ces données, nul besoin de SQL pour le faire.

Par contre si je fais la saisie sur le serveur, il faut que les différents modules de saisie (selon la nature de ce qu'on saisit) aient également accès à la totalité de la base de données, et cela implique en pratique l'utilisation de MySQL.

Je vais donc, à mon corps défendant, devoir réécrire la totalité du code du site en utilisant MySQL pour pouvoir faire la saisie sur le serveur, alors que je pensais pouvoir le faire plus tard.

Je ne manquerai pas de demander leur aide aux experts MySQL dans cette opération.