Date: prev next · Thread: first prev next last
2024 Archives by date, by thread · List index


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 <Thierry.Jeanneret@protonmail.com>
Envoyé : lundi 2 septembre 2024 08:45
À : Ocleyr2lalune <cleyr.listes@free.fr>
Cc : Jean-Michel PIERRE <jmpniort@orange.fr>; François SAINT-CHRISTOPHE 
<francois.saint-christophe@orange.fr>; Liste libOo <users@fr.libreoffice.org>
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 
<cleyr.listes@free.fr<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
<francois.saint-christophe@orange.fr> 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 <jmpniort@orange.fr>
à : "francois.saint-christophe@orange.fr"
<francois.saint-christophe@orange.fr>
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 à users+unsubscribe@fr.libreoffice.org 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 à users+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.