Bonjour, merci pour vos retours. Pour compléter le message de Claire, en ce qui concerne le choix de la solution et de sa remise en cause éventuelle :
* base +calc : c'est la situation actuelle. Pour l'utilisateur çà convient parfaitement. Pour le mainteneur, les interventions sont peu complexes. Le seul point de complexité relative est l'intervention dans Base pour des sélection et tri de données qui peuvent demander des ajustements si les utilisateurs font évoluer leurs besoins. * base : tout seul. Je l'avais évalué. je connais tout ce que pourra m'apporter une logique de SGBD. Je pourrai la mettre en oeuvre, mais j'aurai un frein : le changement d'IHM de saisie pour l'utilisateur, connaissant bien la logique de saisie sur un tableur. Le seul point sur lequel j'aurais besoin d'aide si je me décidais, ce serait sur les rapports, n'ayant pas trouvé de doc sur de documentation suffisamment complète sur certains points. Mais je n'en suis pas là pour le moment. * calc tout seul. Cette solution pourrait m'intéresser car elle simplifierait l'architecture. Au fil des échanges, il m'a été indiqué que calc supportant des fonctions de base de données, c'était réalisable. Lors de la création de l'outil, j'avais investigué et n'avais pas trouvé la façon de la réaliser / à mes besoins. C'est sur cette solution de calc seul que je sollicite la liste. D'où l'objet de mon message du 30/8 22h40, qui donne le lien vers une maquette. Cette dernière a pour objectif de montrer les impasses dans lesquelles je suis tombé en essayant calc seule et la façon que j'ai mis en oeuvre calc+base. En résumé, en quoi ma logique d'utilisation cloche t'elle pour arriver à une logique de BD avec calc seul ? * Pour le message de Jean-Pierre, il mentionne "tableur comme base de données". Il a sans doute une idée précise sur la façon de réaliser cela dans calc. Pourrait il, préciser, même succinctement, sur ma maquette en lien du message du 30/8 22h40, ce qui ne va pas dans ma logique de recherche de fonctionnement BD de calc seul ? Suis je passé à côté d'une fonctionnalité de calc BD ? Merci par avance à tous ________________________________ De : Thierry Jeanneret <[email protected]> Envoyé : lundi 2 septembre 2024 08:45 À : Ocleyr2lalune <[email protected]> Cc : Jean-Michel PIERRE <[email protected]>; François SAINT-CHRISTOPHE <[email protected]>; Liste libOo <[email protected]> Objet : Re : Re: [fr-users] Développement avec base de données : Calc ou Base ? Ayant découvert Base en implémentant une petite gestion pour un artisan il y a quelques années, je trouve extrêmement dommage la réticence de beaucoup à l'utiliser lorsque ce serait pertinent. Ce module marche très bien, est performant pour une application monoposte à taille humaine et ne demande finalement qu'un peu de courage pour s'y mettre. Je lui reproche essentiellement le choix de son moteur de bases de données, dont le SQL souffre de quelques déficiences. Mais elles sont contournables. La création de tables, de formulaires, la définition des relations sont dans mon souvenir simples et intuitives. On peut complexifier un peu quand c'est nécessaire en utilisant un BASIC adapté au domaine, les limites sont plus celles de l'imagination que techniques. En résumé, le tableur comme base de données est une solution "de facilité" qui semble séduisante parce qu'elle permet de très vite montrer un prototype au bon peuple. Mais à terme, c'est un croc en jambes, lourd à maintenir, instable, fouilli. Conseil : Faire l'effort de comprendre qu'un tournevis ne s'utilise pas comme un marteau. Thierry Le dim. 1 sept. 2024 à 22:24, Ocleyr2lalune <[email protected]<mailto:Le%20dim.%201%20sept.%202024%20à%2022:24,%20Ocleyr2lalune%20<<a%20href=>> a écrit : Bonsoir il faudrait éviter les suppositions rapides, d'autant que nous n'aviosn aps les fichiers auparavant. Je n'ai pas eu le temps de les regarder, mais replaçons les choses. Puisqu'il aurait mieux vallu garder le même fil... L'outil actuellement créé utilise Calc & Base. Ainsi si l'on rajoute des calculs dans Calc, ceux ci sont pris en compte dans Base, ce qui n'est pas souhaité... (c'est un raccourci aussi, mais après tout les archives de la liste sont là pour retracer les choses). Il y a déjà eu des interventions pour recommander l'utilisation de Base seul. La réponse donnée etait : non, pas de formulaire de saisie dans Base, ce n'est pas adapté aux utilisateurs cibles. J'ai proposé en 1er lieu pour une évolution minimale, l'utilisation de 2 fichiers Calc, dont un fichier "tampon", qui serait utilisé par Base. Je ne sais pas pourquoi cette solution ne convient pas. Peut être n'est-elle pas adaptée à la problématique, c'est à voir avec les fichiers envoyés. Ensuite, si je reconnais la puissance de Base, on a droit d'être quelques peu réalistes. Si Base est installé en même temps que Calc (sous Windows du moins), cela ne signifie pas que pour un utilisateur standard, la connaissance même trés basique de Base est aussi fréquente que celle de Calc. Bien sur, l'investissement peut être réduit, mais si l'on a l'habitude de travailler auprès d'utilisateurs qui doivent reprendre l'utilisation d'un outil qu'ils n'ont pas conçus : l'utilisation d'un tableur impressionne moins... En résumé, cela fait déjà plusieurs jours que l'on sait que l'ensemble est parfaitement réalisable en intégralité, uniquement dans Base. Ce n'est malgré tout pas la solution retenue par la personne qui pose la question. Qui sait aussi que dans d'autres outils pro, l'ensemble serait aussi parfaitement réalisable. Le prisme d'entrée est donc la maintenabilité, dont les critères sont définis par la personne qui pose la question, et non par les principes d'usage de chaque outil. Donc soit on continue le spaghetti en essayant de combiner Calc et Base ce qui semble délicat, soit on cherche une autre solution. à savoir, est-ce possible dans Calc, même si, rigoureusement, dans Base, ce serait plus adapté. Et oui, ça permettrait une architecture plus simple (que Calc & Base et non que Base seul) Une fois ceci dit, si François est prêt à faire du Base tout court, y compris pour la saisie, banco. Si Jean Michel peut gérer l'effet de bord soumis la semaine dernière entre Calc et Base, banco aussi. De mon coté, les prochains jours sont chargés comme je l'avais déjà dit, il va falloir patienter un peu avant que je puisse regarder ces fichiers (à moins qu'une autre option soit choisie d'ici là !) En tous cas, merci pour les fichiers ! à suivre Claire Le 2024-09-01 08:05, Jean-Michel PIERRE a écrit : > Puisqu’il s’agit de gérer une association et que les calculs sont très > simples à paramétrer dans les requêtes (codes SQL Count ou Sum) ou les > rapports de Base, les conseils de n’utiliser que Calc peuvent être dus > à une méconnaissance de Base. > > > Jean-Michel PIERRE > Tél : 06.19.55.73.22 > >> Le 31 août 2024 à 21:46, François SAINT-CHRISTOPHE >> <[email protected]> a écrit : >> >> >> >> >> Bonsoir, >> >> c'est bien la situation actuelle : j'utilise base et en partie calc. >> Dans des échanges précédents avec la liste, il m'a été indiqué que il >> était possible d'abandonner la partie Base pour tout avoir sous calc. >> Au des exemples fournis, pensez vous que cela soit possible ? En tout >> cas, je n'ai pas réussi. >> >> Cordialement >> >>> envoyé : 31 août 2024 à 17:46 >>> de : Jean Michel PIERRE <[email protected]> >>> à : "[email protected]" >>> <[email protected]> >>> objet : Re: [fr-users] Développement avec base de données : Calc ou >>> Base ? >>> >>> >>> Bonjour, >>> >>> Les États attendus, ainsi que les spécifications souhaitées, semblent >>> tout à fait réalisables directement dans le module Base. >>> >>> Les requêtes dynamiques s'ajustent sans difficulté au nombre >>> adhérents, en choisissant les critères voulus. Il est possible de >>> concaténer prénom et nom et de faire un tri, sur l'un ou l'autre. >>> >>> On peut aussi ajouter la création d'une carte d'adhérent avec sa >>> photo, des listings sur les critères souhaités, par exemple les dates >>> d’adhésion ou de cotisation payée, etc. >>> >>> Enfin, s'il est nécessaire de sortir des données dans Calc, c'est >>> possible directement avec le Rapport de Base, ou comme actuellement >>> en faisant glisser une requête pour la déposer dans le classeur. >>> >>> >>> >>>> Bonsoir >>>> Ces derniers jours, j'ai échangé avec la liste principalement sous 2 >>>> fils de discussion. Au cours de ces échanges, j'ai reçu des >>>> remarques ou propositions d'architecture différente pour un outil >>>> que j'ai développé. Pour éviter de repartir avec des objets de post >>>> qui n'ont plus beaucoup à voir avec le sujet que je veux aborder, je >>>> repars donc avec un nouveau fil d'échanges, en rappelant le >>>> contexte, puis en posant la question qui me préoccupe. >>>> Pour les besoins d'une section d'un club auquel j'appartiens, j'ai >>>> développé un outil qui permet de faire la gestion nécessaire : >>>> - saisie du fichier adhérent dans un .ods >>>> >>>> - à partir de ce fichier adhérents, production des différents sous >>>> produits ou états : état financier des cotisations, liste des >>>> adhérents de la section à destination du club, comparaison >>>> automatique des données avec celles de la fédération nationale, >>>> >>>> - développé sous libre office. Le .ods est également défini en .odb. >>>> Des requêtes attachées à l'odb permettent d'extraire les données et >>>> sont intégrées dans des feuilles de l'ods (1 feuille = 1 sous >>>> produit >>>> >>>> - aucune ligne de programmation ni de macro, ceci pour des raisons >>>> de facilité de maintenance et de prévision de passage de relais vers >>>> une personne maîtrisant les aspects bureautiques mais ne programmant >>>> pas. Tout est basé sur des requêtes, des formules de calcul et des >>>> manip simples pour l'utilisateur. >>>> >>>> Actuellement, la saisie se fait directement dans le .ods, sans >>>> formulaire, avec une validation de données effectuée par la fonction >>>> standard de calcul. >>>> >>>> Lors d'échanges avec la liste, il m'a été proposé de ne plus >>>> utiliser Base et de tout effectuer dans Calc. L'idée parait >>>> intéressante et je pourrai migrer l'outil vers cette nouvelle >>>> architecture, sous réserve : >>>> >>>> * >>>> de ne pas dégrader le fonctionnement pour l'utilisateur, >>>> * >>>> de simplifier l'architecture >>>> * >>>> de conserver une maintenabilité facile possible pour le repreneur de >>>> la maintenance. >>>> >>>> Pour faciliter les échanges et la compréhension de l'architecture et >>>> de ma question, j'ai préparé une maquette reflétant précisément la >>>> technique utilisée mais appliqué sur des fichiers exemples avec peu >>>> de données. >>>> Ci-après un lien qui renvoie vers un fichier ods et vers un fichier >>>> odb (l'odb n'a pas besoin d'être référencé dans LO). >>>> Dans le fichier ods, plusieurs feuilles. La 1ère comporte un texte >>>> expliquant chaque feuille. La succession de ces feuilles a été faite >>>> dans l'ordre où j'ai raisonné et testé pour ai final, mettre en >>>> oeuvre la solution calc+base : >>>> >>>> * >>>> une feuille données saisies, >>>> * >>>> puis l'image d'un état tel que je le souhaite avec 10 lignes, et 14 >>>> lignes de données, >>>> * >>>> puis les résultats obtenus avec 2 méthodes sous calc seul >>>> * >>>> et enfin, la dernière feuille contient la solution calc+base. >>>> >>>> Peut être suis je arrivé à cette solution en étant passé à côté des >>>> fonctionnalités BD de Calc tout seul. Je sollicite donc les membres >>>> de la liste pour leurs propositions éventuelles de solutions >>>> alternatives plus simples. >>>> >>>> Merci par avance >>>> >>>> Lien vers fichiers maquette >>>> https://partage.isidorus.fr/f.php?h=1U_nDfCk&d=1 >>>> >>>> >>> >>> -- >>> Jean-Michel PIERRE >>> 19 rue François VILLON >>> 79000 NIORT >>> tél : 0619557322 -- Claire -- Envoyez un mail à [email protected] pour vous désinscrire Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/ Privacy Policy: https://www.documentfoundation.org/privacy -- Envoyez un mail à [email protected] pour vous désinscrire Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/ Privacy Policy: https://www.documentfoundation.org/privacy
