Bonsoir,
Le 27/09/2020 à 11:34, Patrick Auclair a écrit :
Bonjour,
Je viens de terminer la relecture du chapitre 1. Comme Francis, je 
trouve ce chapitre en l'état très complexe.
Pour moi, et cela n'engage que moi, il a été très mal construit dès le 
départ, cela n'a rien à voir avec ta traduction Jean-Michel.
J'en veux pour preuve la base de test n'est pas un bon modèle pour 
débuter à cause de l'emploi de calculs sur les dates.
Calculs qui en plus donnent des résultats en partie faux (Le 
participant qui n'a pas encore fêté son anniversaire). Les calculs sur 
les dates en SQL sont, et ont toujours été pour moi, quelque chose de 
complexe et très sensible.
En partie d'accord avec tes remarques, mais je suis un mauvais client, 
car j'ai beaucoup travaillé avec Base, donc ça ma paraît probablement 
plus simple.
Effectivement il y a un petit souci avec l'âge quand on n'a pas encore 
fêté son anniversaire, ce n'est pas une erreur, c'est parfaitement 
décrit et assumé dans les explications., Il ne s'agit que de créer des 
groupes d'âges homogènes. C'est comme cela que sont gérées les 
catégories dans les clubs (benjamins, minimes, cadets) et les 
affectations dans les classes de maternelle :-)
Ce problème est évoqué (et rectifié) dans l'exemple 
*Rapport_Lignes_Colorées_Alternées.odb *dans le chapitre 6 consacré aux 
rapports*.*
A ce sujet, je me suis permis d'ajouter une requête SQL (Page 39) qui, 
elle, permet de calculer l'âge correct d'une personne, bien sur avec 
des explications.
Dites-moi ce que vous pensez de cet ajout ?
Je ne sais pas si ça ne vient pas complexifier un peu plus le sujet ?
Mais, a-t-on le droit de modifier un chapitre au lieu de seulement le 
traduire ?
On peut parfaitement, je l'avais d'ailleurs fait dans ce même document.
De plus, même si un utilisateur est sensé avoir un minimum de 
connaissance en matière de base de données avant de se lancer avec 
Base, certaines notions sur l'informatisation d'un système 
d'informations auraient dues être rappelées.
En effet, on ne construit pas une base directement en ajoutant ici et 
là des tables, relations requêtes, formulaires, .....
D'accord avec ça aussi, bien entendu. Mais ça n'est quand même pas fait 
au hasard.....
A mon sens, il s'agit d'une introduction, pour survoler tous les 
chapitres et donner une idée des possibilités du module, avec tout de 
même quelques règles, et en supposant qu'il y a eu une réflexion 
préalable, rapide certes, puisqu'il n'y a que trois tables.
Construire le dictionnaire de données, établir les résultats que l'on 
souhaite obtenir, etc, bref appliquer une méthode (Merise, Uml) est 
primordial.
Ça peut être l'objet d'un autre document, pertinent et utile, mais qui 
sort du cadre LibreOffice ?
Sans entrer dans les détails (il existe pour cela d'excellents tuto en 
ligne), une partie du chapitre pourrait-être consacré à cela.
Mais est-ce possible ? Ne vaudrait-il pas mieux introduire un nouveau 
chapitre uniquement sur ce sujet ?
Parfaitement d'accord !
Bonne soirée
--
Jean-Michel COSTE
--
Envoyez un mail à doc+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/doc/
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.