Bonjour,
je ne suis pas un grand specialiste du PHP et de la programmation "Web" en général mais je me débrouille.
J'écris un plugin pour Galette pour nous permettre de gérer les spécificités de notre association sportive (gestion de résultats de compétition, challenges, etc…).
J'ai les bases qui fonctionnent (il faudra que je nettoie un peu à un moment mais ce n'est pas l'objet ici).
Mon code se découpe en 5 familles:
- gestion des parcours
- gestion des competitions (qui intègrent 1 à N parcours)
- gestion des courses (c'est en fait une instance de competition pour 1 date donnée)
- gestion des résultats
et enfin, la gestion des distances. INitialement, c'était un objet spécifique mais à l'usage, cela se révèle inutile et peu pratique (je tablais sur une gestion d'une vingtaine de distance: 100m, 200m, etc… 100km) mais je me retrouve avec des milliers d'entrées… Je souhaite donc intégrer cette notion de distance au niveau de mon objet parcours.
Une Distance c'est une donc une distance (stockée en m par convention et facilité), un nom pour l'affichage (ex: 100km, marathon, etc.) et un format de saisie du temps (h:m:s par défaut mais possible en m:s, jours, etc.). Plutot que d'ajouter des champs à n'en plus finir dans ma table parcours, je voulais ajouter un champs "batard" en JSON mais voilà, je ne sais pas manipuler cet type de chose.
Première question: est-ce bien raisonnable comme démarche ?
Deuxième: comment manipuler ce genre de bestiole simplement ? (stockage, récupération, etc…)
Merci de votre aide.
# Éclaircissements
Posté par gUI (Mastodon) . Évalué à 4.
Si je comprends bien :
- une compétition peut proposer les parcours 2km, 5km et 10km
- un parcours de 10km aura une distance de 10201m dans une compétition, et de 10437m dans une autre
C'est ça ?
Si oui, je mettrais la distance comme une propriété de la relation compétition/parcours, tout comme le temps de la course est une propriété de la relation sportif/parcours
Le fait que le 5km du Marathon de la Savrière fait 5143m est à coder exactement comme le fait que Robert Tripoux a fait le 5km du Marathon de la Savrière en 22'32".
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Éclaircissements
Posté par Xavier Maillard . Évalué à 1.
Effectivement, ça se tient.
Le modèle dont j'hérite est difficilement "modifiable" au risque de perdre des années d'archives mais je comprends bien ta proposition.
Donc, exit le JSON, on est d'accord ?
[^] # Re: Éclaircissements
Posté par gUI (Mastodon) . Évalué à 3.
Hors de question de perdre des années d'archive évidemment. Mais récupérer l'historique et tout remettre dans une BdD propre flambant neuve ça peut être sympa pour les améliorations futures. Mais c'est du boulot.
Ça c'est plutôt l'implémentation, c'est pas trop mon domaine. Mais comme tout soft basé à 95% sur de la consultation/modification de BdD, je te conseille vivement de passer du temps sur ton modèle.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# les formats simples sont les meilleurs
Posté par NeoX . Évalué à 4. Dernière modification le 24 novembre 2018 à 09:30.
pour la distance, tu fais la saisie en metres, et dans l'afficheur tu transforme en KM (avec ou sans virgule) :
10142m => 10km ou 10,142km
pour les temps, tu fais pareil, tu stockes la valeur dans la base en (milli)seconde
mais tu convertis à partir de ce champs en mois/jour/heure/minute/seconde(/milliseconde)
ton formulaire du chrono à ton possiblement 5 ou 6 champs
ou bien tu appliques un filtre de la forme m/j/h/min/sec/ms
ainsi si demain tu veux changer ton affichage des scores de 45h15min70ms en 1j21h15min70ms
tu as bien toutes les infos dans la base, et ce n'est qu'une question de code d'affichage
[^] # Re: les formats simples sont les meilleurs
Posté par Xavier Maillard . Évalué à 1.
Ca se tient.
Donc ca rejoint bien l'avis de gUI: pas besoin de cette bestiole de JSON (ca m'arrange ;)).
[^] # Re: les formats simples sont les meilleurs
Posté par NeoX . Évalué à 4.
le JSON est plutot un format de transmission d'information
donc si tu fais un logiciel client/serveur,
ton client demande un info à un service,
le serveur recoit la demande, va chercher dans la base, et va transmettre un json à ton logiciel
genre
et c'est ton logiciel qui prend ces infos, et les decode pour les afficher comme il veut.
ton serveur peut alors etre interfacé avec d'autres clients, le serveur de la fédération par exemple, ou bien une appli mobile/tablette.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.