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 
dim. 1 sept. 2024 à 22:24, Ocleyr2lalune <<a href=)> 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

Répondre à